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Abstract 



A data abstfactioA fritreduces a dau type iwth a hidden representation Specifications 
of data abstractions are required to allow the data to be described and used without reference to 
the underlying representation. There are two main approaches to specifying data abstractions, 
the abstract model approach and the axiomatic approach. 

This thesis is concerned with the problems of formalizing and extending the abstract 
model approach. A formally defined language for writing abstract model specifications is 
presented. The correctness of an implementation with respect to an abstract model specification 
is defined, and a method for proving the correctness of implementations is proposed. 

Our formulation treats data abstractions with operations that can dynamically create 
new data objects, modify the properties of existing data objects, and raise exception conditions 
when presented with unusual input values. 
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1. Introduction 

Specifications play an important part in the programming process, especially in the 
design and construction of large programs. It is generally accepted that large programs should 
be designed as systems of loosely coupled independent modules, so that each module can be 
designed and understood without reference to the other modules. A precise specification of the 
behavior of a module decouples the programs that use a module from the programs that 
implement the module, since programs that use the module depend on the specification of the 
module rather than on the implementation. The hope is that the specifications of a module will 
usually be simpler and more stable than the implementation of the module, so that the use of 
the specifications will make It easier to design, implement, and maintain the modules that make 
up a program. Specifications are also needed for program verification. 

The research reported here is primarily concerned with specifications for data 
abstractions. A data abstraction consists of a set of data objects and a set of primitive 
operations on those objects. The objects of a data abstraction are treated as abstract indivisible 
entities, which do not have any directly accessible substructure. The objects of a data 
abstraction can be manipulated only by means of the primitive operations provided by the data 
abstraction.' The behavior of a data abstraction is completely characterized by the behavior of 
its primitive operations, and the observable properties of the abstraction are precisely those 
computable in terms of the primitive operations. Since the behavior of a data abstraction is 



I. The only exception to this rule is the boolean abstraction. The host programming language 
may provide statements, such as the conditional, which make the flow of control depend directly 
on a boolean value. These statements are not primitive operations of the boolean abstraction, 
and they cannot be defined using only the primitive operations. 



independent of the way in which the associated data objects are represented in any particular 
implementation, introducing data abstractions is one way of decomposing a program into 
independent modules [39, 40, 19, 4, 291 The concept of representation independence is made 
more precise by the definition of behavioral equivalence of data models developed in Chapter 3, 
and it is the basis for the usual data type induction rule 1531 

To specify the behavior of a data abstraction, it is sufficient to specify the behavior of 
each operation, since the only way to interact with the objects of a data abstraction is by means 
of the primitive operations. The problem of specifying the operations of a data abstraction 
differs from the problem of specifying procedures because the specification of a data abstraction 
must be independent of the way the associated data objects are represented in any particular 
implementation of the abstraction. There are two mam approaches to specifying data 
abstractions, the abstract model approach and the axiomatic approach. 

In the abstract model approach, an abstract representation for the data objects is 
defined, and the operations are specified in terms of the abstract representation. The 
representation is abstract because it is constructed from mathematically defined domains, rather 
than the built in data types of some programming language. The abstract representation 
should be chosen so that the operations can be defined as simply at possible. The 
representation used in the implementation of a data abstraction must often be chosen to 
optimize space or time efficiency, and may be quite different from the abstract representation. 
To prove the correctness of an implementation with respect to an abstract model specification, it 
is necessary to define the correspondence between the representation used in the implementation 
and the abstract representation. 

In the axiomatic approach, the set of data objects is defined implicitly, by giving a set 
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of axioms relating the primitive operations. The axioms specify the relationships that must 
hold between the operations of a data abstraction, and any structure satisfying the axioms is 
taken to be an acceptable model for the abstraction. If the axioms are consistent, then there will 
be at least one structure satisfying the axioms. It is possible for many different structures to 
satisfy the same set of axioms. To establish the correctness of an implementation with respect to 
an axiomatic specification, it is necessary to show that the operations of the implementation 
satisfy the axioms. An excellent treatment of correctness proofs based on axiomatic 
specifications can be found in [37]. 

The work reported here is concerned mainly with formalizing and extending the 
abstract model specification technique. We present a formally defined language for writing 
abstract model specifications. A criterion for judging the correctness of an implementation of a 
data abstraction with respect to an abstract model specification is developed, along with a 
method for proving that particular implementations are correct with respect to specifications in 
our specification language. Both the specification language and the proof technique apply to 
situations where mutable data can be shared. Previous work on specifications has largely 
avoided the issues associated with shared mutable data. Our formulation provides an 
integrated treatment of data abstractions with operations that can dynamically create new data 
objects, modify existing data objects, or raise exception conditions when presented with unusual 
Input values. 
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1*1 Previous Work 

Most high level programming languages , b^ye, >r a f set of built in data abstractions. 
Languages that support user defined data abstractions have bees* developed, including 
SIMULA 67 [51 CLU [291 and ALPHARD J5J0. , In these languages a^ogram using a data 
abstraction does not have to mention the representation of that abstraction, so that the 
implementation structure can be changed without affecting any of the application* programs 
using the abstraction. 

Surveys of specification techniques for 4af$ abstractions can be found In [31] and in 
[281 

The abstract model approach is direct in {he sense that the set of data objects 
associated with a data abstraction is explicitly constructed. References to early work on abstract 
model specifications can be found in [311 The problem of proving the correctness Ol an 
implementation of a data abstraction with respect to an abstract model specification has been 
treated by Hoare in [181 and the problem of proving the correctness of programs using the 
objects and operations of a data abstraction has been treated by Shaw in [471 In botb cases, 
the specification language has been introduced informally, and shared dat» has been excluded. 
The problem of specifying the behavior of data shared by concurrent processes has been treated 
in the context of the actor formalism by Yonezawa in [551 

The abstract model approach ii related to the denotational definition method for 
programming languages developed at Oxford by Scott and Strachey [49, 461 in which a 
mathematical model is defined for each of the constructs of a programming language, including 
the data domains. The major emphasis of the work at Oxford has been directed at issues other 
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than data abstractions. A formal treatment of a language with the potential for sharing 
mutable data can be found in [50], although the model makes little attempt to abstract from the 
storage representation of the data. A denotational definition of CLU, a language with facilities 
for constructing user defined data abstractions, can be found in [45]. 

The axiomatic approach is indirect in the sense that the set of data objects associated 
with a data abstraction is defined implicitly. There are several different axiomatic specification 
techniques, which are distinguished by the kind of logic in which the axioms are embedded. 

Axiomatizations of data abstractions in first order logic can be found in [19]. A first 
order logical approach has also been used in the iota system [37] for constructing and verifying 
programs that use data abstractions. 

A restricted form of axiomatic specification using only conditionals and equations has 
come to be known as the algebraic approach [56, 10, 7, 13, 9]. The name stems from a uniform 
method for constructing a canonical model for axiomatiiations expressed in this form. The 
canonical model is a many sorted algebra which is unique up to isomorphism, and which is 
called the initial algebra. A system for verifying programs using data abstractions specified by 
algebraic specifications has been developed at 1SI [35, II, 36]. 

The problem of proving properties of programs that manipulate potentially shared 
mutable list structures has been treated by Burstall in [2]. Burstall follows a hybrid approach, 
by explicitly introducing a model and defining its behavior axiomatically. Proofs about 
programs that manipulate pointers have been treated by Suzuki and Luckham [51, 32]. 

An approach to defining programming languages combining aspects of the direct and 
indirect approaches is being developed by Schaffert [44]. Schaffert treats shared mutable data 
abstractly, and considers the problem of proving properties of programs using mutable data 
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abstractions. 

1.3 Motiviations for this Work 

The original aim of this research was to develop tools and techniques for increasing 
the level of confidence that a formal specification for a data abstraction does indeed capture the 
behavior intended by the designer: We started with the algebraic specification technique, as 
described by the work ofZiftes [56] and Guttag [Mtt 

After some preliminary investigation, it became clear that there were a number of 
phenomena associated with the data types actually used by programmers that could not be 
adequately described by this specification technique as it stood, notably the dynamic creation of 
data objects; changes of state of potentially shared data, and exception handling. 

It also appeared to be difficult to produce a well formed algebraic specification for a 
new data abstraction, especially if the exact behavior required was not yet completely designed. 
In oUr experience, a typical attempt t6 design a data abstraction using axiomatic specifications 
runs as follows. After analyzing the problem, the operations of the data abstraction are 
determined, and the inputs and outputs of each operation are identified. When the intended 
behavior of each operation on a typical set of input values is fairly well understood, a 
preliminary axiomatization is constructed, the process of producing the preliminary 
automatization helps to pinpoint special cases and boundary values for the input domain, and 
the problem is analyzed further to determine appropriate behavior for the operation on unusual 
or ill formed input values. The axioms are examined in light of the new design decisions and 
are adjusted to conform. After a few iterations each of the axioms looks plausible when 
considered in isolation. At this point the axiomatization is examined for consistency and 
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completeness. often at the cost of considerable effort. Fairly often we have found such an 
axiomatization to be inconsistent, and less often to be incomplete. It was disturbing to find that 
plausible axiomatizations could be ill formed, and that the effort of producing a precise 
description of a seeming simple design decision could be quite large. 

We also designed some data abstractions using abstract model specifications, and 
found that the process was much easier. One point was that inconsistencies in the design would 
usually surface immediately, because it would not be possible to define some operation so that it 
satisfied all of the informal constraints, while the usual result of trying to axiomatize an 
inconsistent set of design decisions was a inconsistent axiomatization, which was often difficult 
to recognize as inconsistent. Another point was that minor perturbations in the behavior of an 
operation were easier to describe for an abstract model specification than for an axiomatic 
specification. As long as the meaning of the abstract representation is not changed, a 
modification in the definition of one operation cannot affect the other operations, since in an 
abstract model each operation is defined in terms of its effect on the abstract representation. In 
an axiomatic specification the meanings of the operations are defined in terms of the relations 
between them, so that a change in an axiom can affect many operations. 

While the above is a very subjective judgment, based on our personal experience with 
a fairly small set of examples, we found that other people trying to use axiomatic specifications 
in the design process had similar complaints. This motivated a more extensive investigation of 
abstract model specifications. 

We found that previous work on abstract model specifications was largely Informal, 
and that abstract model specifications were used without saying what the specification language 
was or what the specifications meant. Since abstract model specifications appeared to have 
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advantages From the point of view of design, establishing a precise mathematical formulation of 
the specification technique arose as a natural subgoat. In ihe process of pursuing this goat it 
became apparent that dynamic creation of data objects, state changes, and exception conditions 
could be readily incorporated into ihe framework. At that time, existing work on axiomatic 
specifications did not address these issues, ^hkh kept cropping up in the design of programs. 
As a result, the direction of this research shifted to developing and extending the abstract 
model specification technique, and fhe^ original problem wadset *side as a subject for future 
investigation. 

1.3 Assumptions and Restrictions 

fn the interests of defining a problem that can be treated in depth in a reasonable 
amount of rime, we have made some restrictions on the scope of oftr investigation. The*e 
restrictions are explicitly stated below: A more detailed discussion of the restrictions and the 
reasons ; for introducing them can be found m Appendix t 

We have not considered cases where mutable data is shared by concurrent processes, 
so that a model of a computation as a linear sequence of operations is sufficient for our 
purposes We have assumed that each operation is deterministic, so that every computation 
produces a unique result. These assumptions lead to a simpler characterization of the 
observable behavior of a data abstraction than would otherwise be possible 

We have adopted a model of exception handling in which operations are terminated 
if they raise an exception condition. This restriction allows the behavior of an operation to be 
described independently of the behavior of exception handlers and exception handling 
mechanisms, and teads to a clean model of data behavior. 
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We have assumed that each operation depends only on the properties of the data 
objects passed to the operation as arguments. Operations that depend on global data or on own 
data (i.e., operations with internal state) are excluded by this assumption. Without such a 
restriction on the operations, systems must be treated where the behavior of a data object may 
be affected without applying any of the primitive operations associated with the data 
abstraction, and the concept of behavioral equivalence (see Chapter 3) must be reformulated. 
Since the behavior of such structures is not completely characterized by the behavior of the 
primitive operations, we do not accept them as well formed data abstractions. 

1.4 Results of this Work 

We have investigated the structure of mathematical models of data abstractions, 
developed a general framework for proving the correctness of implementations, and proposed a 
prototype specification language based on these results. 

1.4-1 Mathematical Models 

A specification can be viewed as a method for singling out the structures (or models) 
that exhibit the desired behavior from those that do noj, and the meanings of a specification can 
be identified with the class of models consistent with the specification. This gives us a basis for 
judging whether or not two specifications in two different formalisms have the same meaning. 
The set of structures consistent with a given axiomatic specification contains precisely those 
structures in which all of the axioms are true. An abstract model specification defines a 
particular model exhibiting the desired behavior, and the class of all models consistent with the 
specification contains just those structures with the same externally observable behavior as the 
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standard model. In this work, we have formally characterized the aspects of the behavior of a 
data abstraction that are detectable by an external observer. 

We have described two classes of algebraic structures, exception algebras and state 
machines, which can be used as models for data abstractions with exception conditions and with 
state changes. This work win be of interest to people wishing to extend the axiomatic technique 
to include exceptions and state changes, since it explores the kinds of structures that will have to 
be defined axiomatically. 

1.4.2 Proof Techniques 

In treating a range of behavior including object creation, mutation of data, and 
exceptions, we have found it necessary to reformulate the criteria for the correctness of a 
proposed implementation of a data abstraction, and to develop new techniques for proving the 
correctness of an implementation with respect to the new criteria. These techniques are of 
interest also to people who wish to verify mutable iffil^ilMu6liP of flatfr abstractions #rtH 
respect to axiomatic specifications. 

1*4.3 Specification Language 

■■-•.—••_. ■■■;.■.-■>■-'■■■ .-.*■-■.■■..■:■-.;. ..■ ^ ■■'■"* 

We have developed a specification language for defining data abstractions based on 
abstract models. This language has been given a mathematical definition that is sufficiently 
formal to support mathematical proofs of properties of the specification, and of the correctness 
of implementations. We have made an effort to incorporate all of the features necessary for a 
practical specification language, rather than to define a language designed to facilitate proofs of 
meta-theorems about the specification language. We have intended this language to serve as a 
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prototype, which can be used as a guide for people designing practical specification languages. 
The language presented here has been designed primarily to be read and written by humans, 
lather than to be mechanically processed (e.g., by a program verification system). In some 
applications it may be desirable to use a more restricted language, in order to facilitate 
automatic theorem proving at the expense of making the specifications harder to construct. 

1.5 Overview of Remaining Chapters 

In Chapter 2 we explain the novel aspects of data behavior associated with exception 
conditions, dynamic allocation, and mutation of potentially shared data, and describe algebraic 
structures suitable for modeling that behavior. 

In Chapter 3 we formally define the externally observable behavior of a data 
abstraction. The meaning of a data abstraction is associated with the class of all structures 
exhibiting the same externally observable behavior. The concept of a reduced model for a data 
abstraction is developed and explored. 

In Chapter 4 we present a specification language for constructing models, along with a 
mathematical definition for the semantics of the language. Each well formed expression of the 
language denotes an algebraic model. The construction of the model is explained, and the 
requirements an expression must satisfy in order to be a well formed specification are 
established. 

In Chapter 5 we state our basic definition of the correctness of an implementation, and 
develop a methodology for proving the correctness of an implementation with respect to a 
standard model for the data abstraction to be implemented. The methodology is illustrated by 
examples of correctness proofs. The basic definition depends on the material in Chapter 3, 
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while the examples use the language developed in Chapter 4. 

Chapter 6 contains our conclusions, a comparison of the abstract model specification 
technique to the algebraic technique, and indications of directions for future research. 
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2. Modeling Data Behavior 

We will define the behavior of a data abstraction by constructing a standard model 
e*hibiMhg that behavior. A model is a mathematical structure containing interpretations for 
the objects and operations of the data abstraction. The externally observable behavior of a 
data abstraction consists of the results of all finite computations composed from the primitive 
operations of the data abstraction and yielding objects of other types." An abstract model is 
fised to specify the externally observable behavior of a data abstraction. All properties of a 
model that are not externally observable are irrelevant, in the sense that they do not influence 
whether or not a proposed implementation of a data ab^ to tSe 

standard model. We will say that two models are behavior ally equivalent if and only if they 
have the same externally observable behavior. * If two structures are behavioratly equivalent 
then they are models of the same data abstraction. Behavioral equivalence is treated in depth 
m Chapter 3. 

The standard model is intended to be a isomorphic image of the data abstraction as 
conceived by the designer: every object of the data abstraction imagined by the designer should 
correspond to a unique object in the standard model, and the correspondence should preserve 
the operations. The standard model of an abstraction can be identified with the structure 
conceived by the designer, thus bridging the gap between the inaccessible pattern in the 



I. Except for the boolean abstraction, the only way to interact with the objects of a data 
abstraction is by means of the primitive operations, so that the only way to export any 
information from an abstract type is by means of the primitive operations yielding results of 
some other type. The interested reader may wish to compare this idea with the treatment of 
sufficient completeness in [10]. 
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designer's head and a publicly accessible mathematical structure. A well designed standard 
model should be reduced: it should not be possible to delete an object from the fnodel or to 
coalesce two distinct objects without affecting thjs exteTOllic^^abteb^M^tor^ the modd. 
The concept of a reduced model is discussed further in Chapter 3. 

In this chapter we wiH consider various aspects of the behavior of a data abstraction, 
and show how they can be modeled using algebraic structures, but first wt have to briefly 
examine the internal structure of a data abstraction and the ways in which a set of data 
abstractions can be related to each other. 

2.1 Types And Subordinate Abstractions 

We will call a set of data objects subject to the same operations a type. Ttye definition 
of a new data abstraction introduces a new type, the ^netful tj}t nX, the abstraction, Each 
operation of the abstraction involves objects of the principal type, and often also objects of 
other types, which we will call the subordinate types of the data abstraction. For example, the 
set of integers is the principal type of the integer data abstraction, and the set of boolean s Js a 
subordinate type, because the integer abstraction has the operations - and < which map pairs of 
integers into booleans. Every type is the principal type of some unique data abstraction, known 
as the defining abstraction of the type. The primitive operations on the objects of a type are 
just the operations of its defining abstraction. 

A model for a data abstraction must contain interpretations for the principal type and 
operations, and also for the subordinate types, because the operations involve objects of the 
subordinate types as well as of the principal type. Each of the subordinate types of a data 
abstraction d is the principal type of its defining abstraction rf\ Thus we are usually dealing 
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with a set of related data abstractions, and with a set of related models for those abstractions. 
We will assume that systems of data abstractions are defined incrementally, where the definition 
of a model for a new data abstraction explicitly introduces an interpretation for its principal 
type, and where the interpretations for the subordinate types are taken from the models for the 
defining abstractions for those types. This construction guarantees that a type is not given two 
different interpretations in a single system of models. However, a bit of caution is required, 
because it may not always be possible to define the data abstractions in a system in an order 
such that the defining abstractions of the subordinate types of each data abstraction are defined 
before the data abstraction itself. For example, suppose that the fixed point number abstraction 
has an operation for converting fixed point numbers to floating point, and that the floating 
point abstraction has an operation for converting floating point numbers to fixed point, say by 
rounding. In such a case, floating point numbers are a subordinate type for the fixed point 
number abstraction, and vice versa, so that it is not possible to define both types in an order 
such that their subordinate types have been previously defined. 

In order to make the idea of a hierarchically ordered set of type definitions more 
precise, we define the direct subordinate and subordinate relations as follows. 

Definition 1 Direct subordinate relation. 

If dj and ^ are data abstractions, then dj is a direct subordinate of <<2 If and 
only if the principal type of dj is a subordinate type of dy. 

Definition 2 Subordinate relation 

The subordinate relation is the transitive closure of the direct subordinate 
relation. 

We would like the subordinate relation to be a well founded partial order, but this need not 

always be the case, because two data abstractions can be subordinate to each other, as in the 
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above example. However, if we group together all of the data abstractions that are mutually 
subordinate (i.e.. take the quotient with respect to the largest equivalence relation contained in 
subordinate), then the subordinate relation does in fact induce a partial order on the groups 
(equivalence classes). 

We will treat each group of mutually subordinate data abstractions as a single 
module. A model for such a module wilt have several principal types, one for each data 
abstraction. Modules correspond to the equivalence classes introduced in the previous 
paragraph. The subordinate relation for modules is always a partial ordering. This ordering 
is also well founded, because the set of data abstractions in any real system is finite. Since the 
ordering is well founded, we can use structural induction with respect to the subordinate 
relation on modules when proving properties of systems of data abstractions (i.e, to establish a 
property for the data abstractions in the module m, we can assume the property holds for all 
abstractions subordinate to m). 

It will usually be the case that each module defines a single data abstraction, with a 
single principal type. In the following discussion we wilt often tacitly assume that each model 
has only a single principal type, although the formal definitions wiH be formulated to deal with 
any number of principal types per model. 

2.2 Simple Abstractions 

The purpose of a standard model specification is to provide an interpretation for each 
type and for each operation of the data abstraction it specifies. A well chosen standard model 
should provide interpretations that are clean and simple. The most suitable modeling structures 
depend on the kinds of behavior that must be described. The simplest case is a data 
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abstraction without any exception conditions or any time dependent behavior, because in such a 
case the types can be interpreted as fixed sets of constant values, and the operations can be 
interpreted as functions on those sets. We will refer to this kind of abstraction as a simple data 
abstraction. The early work on algebraic specifications for data abstractions [56, 10, 7] dealt 
primarily with simple abstractions. Following their lead, we will model simple abstractions as 
heterogeneous algebras [I]. 

A heterogeneous algebra, also known as a many sorted algebra, is a pair <P, F>. where 
P - { P a | a < A } is an indexed set of phyla (also called carriers), and where 
P = { F@ I (9 f B } is an indexed set of operations. The index sets A and B contain the names 
of the types and operations, respectively. Each phylum in P is a set of data objects. Each 
operation in F is a function Fa : P a @ y x ... x P a @ n ^ -» P^ay where n : B -> N, 
a : B x N— * A, and r -. B -*■ A are functions such that «09) > is the number of arguments 
for Fq, a(0, k) is the type index for the k-tb argument of Fa, and r(/3) is the type index for the 
return value of Fq, and where N is the set of all natural numbers. The principal and 
subordinate types of a constant data abstraction are interpreted as the phyla of the algebra, and 
the operations of the data abstraction are interpreted as the operations of the algebra. 

Simple data abstractions are easy to describe, but they represent a very restricted class 
of abstractions, which almost never occur in practice. For example, the fixed point number 
abstraction, a common and relatively simple data abstraction, fails to qualify as a constant data 
abstraction on two counts. First, an attempt to divide by zero results in an exception condition. 
Second, fixed point numbers have a print operation, which modifies the state of an output 
stream. Exception conditions and state changes are discussed in detail beiow. 
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2.3 Exception Conditions 

Many programming language* tave data ^^a^^ 
errors or raise exception ctmHiUms (we preferthe tatter termf; A cornmbn example is the integer 
data abstraction, where an attempt to divide by ^IM'' J H!^''lJt ; «lri^^i^^' : fo''geiimi an 
operation should raise an exception whenever it is called with an argument outside Its natural 
domain of definition. SMtwtiOiis Hke this »re qaite common, so that it is important to include 
exceptions m our rnodd of data abstractions 

2.3.1 Termination vs. Resumption 

An exception causes a departure from the normal flow of control, to execute a program 
fragment intended to A<rmi/* t be excepts I condition, m eases Where trW exception handler 
can recovenfrom the exception, the computation rraf continue, and otherwise it must be 
aborted. There is no universally accepted model for this process. 

One viewpoint, which we shaH adopt, h that an operation may have a number of 
return points, one for the normal case .and one for each exception We shall refer to this j 
viewpoint as the termination model of exception handling. According to the termination model, 
raising an exception is just a special way of terminating an operation. 

An alternative viewpoint, which h co mm o nl y held, is that an exception causes the 
exception handler to be invoked as a procedure, with the implication that the operation that 
raised the exception will continue after the handler returns. We wilt refer to this viewpoint as 
the resumption model of exception handling. 

Both alternatives have been implemented. For example, in CLU an exception 
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conditions always terminates the operation that raised it, while in PL/I the operation is resumed 
(for one class of exception conditions). A detailed analysis and comparison of the termination 
and resumption models can be found in [30], where it is argued that the termination model has 
a much simpler behavior than the resumption model. 

2.3.2 Termination Conditions 

We will assume that an operation of a data abstraction may terminate in any of a 
number of termination conditions [cf. 43], one of which (the normal condition) corresponds to 
the normal behavior of the operation, while the others correspond to the exception conditions 
that may be raised by the operation. The effects of an operation and the number and types of 
return values will usually depend on the termination condition. For motivational purposes, we 
will assume that when an exception occurs, the data objects produced by the operation, if any, 
are passed to the appropriate exception handler as arguments. 2 

A specification for a data abstraction with exceptions must therefore specify when each 
exception occurs, and what the results of the operation are for each termination condition. The 
definition of the host language must specify which error handler is associated with each 
occurrence of an exception, and what happens after the handler terminates. The only constraint 
we impose on the host language is that whenever an operation raises an exception, the 
operation is terminated before the handler is invoked, arid may not be restarted.' 



2. This corresponds closely to the exception mechanism in CLU. In other languages, more 
roundabout methods may have to be used for passing information to an exception handler, 
such as assigning values to global variables. 

3. This constraint is implicit in £103 and [8]. 
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2.3.3 Exception Algebras 

In order to get a class of structures suitable for modeling data abstractions with 
exceptions, we have to extend the notion of a heterogeneous algebra. In a. heterogeneous 
algebra as described in [IX each operation is a function whose range is some phylum of the 
algebra, but a typical operation of a data abstraction tttay return f nWe thaii one data object, and 
it may return objects of different types in different termination conditions. Rather than 
introducing phyla with a complicated substructure, we prefer to relax the constraint on the 
allowable ranges of the operations, since we would like to maintain a simple correspondence 
between the types of a data abstraction and the phyla of the modeling structure. In an 
exception algebra, the range of a typical operation is the disjoint union of a family of , sets, each 
of which is a cartesian product of some number of phyla (possibly zero* ). 

We will also include the index sets and the functions describing the types of the 
operations as explicit components of the exception algebra, to prevent confusion in situations 
where we are dealing with several algebras in the same context. 



Definition 3 Exception algebra i- 

An exception algebra is a tuple < phyla : P, operations : F, arglength : n, argtype : a, 
tc •: t, rJength : m, rtype* r, typehames • Jf- opnalnW: ^flch«n% ?7*f pt : D ). where 
P - { P a | a < A } is an indexed set of phyla, and where F - f Fg 1 c B ) is an 

indexed set of operations, such that each operation in F is a function 

F fi : p a(0. i) * x p m.nm) ~* u \Htt ' #4 wh ^ e W #^^ * e &*&& 

union operation, and where R T « P^ T> j) x ... x P^ t mfl3 T)) n : B ~~* "■ 
a B xH~+ A, r:B-» P(T), m.BxT-+H, r BxT xU~+ A are functions 
such that n(0) is the number of arguments for Fa ««9, *) is the type index for the 

*-th argument of FQ,t0yb the set of ali tennmaiion conditions that may result from 



4. The empty cartesian product is a singleton set containing the empty sequence. 
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F@. w(0, T) is the number of objects returned by Fa ,»" the termination condition T, 

and r(0, T, *) is the type index for the fc-th return vakie of Fg in the termination 

condition T. A is the set of type names, &is theasetrf operation wames, 7" is the set 
of termination condition names, and D £ A contains the names of the distinguished 
principal types. N is the set of natural numbers. 

The details of this formal definition of an exception algebra will be used primarily in Chapter 

3, and in the proofs of the theorems in Appendix HI, The following example may help to 

clarify the meaning of the various components of an exception algebra. Let A be an exception 

algebra nvxiel foi the integer data abstraction. Then we have: , 

A. typenames - { "int", "boolean" } 

,4.opnames« { "plus", "time*^ "difflerence", ,, qHOt|e^H^ -. I 

A. tcnames - } "normal", "zero.divide" } 

i4.pt «■{ "int"} 

A. phyla int = { 0, 1. -I, 2. -2, ... } 

'*-P h r*»booleah-< T ' F ) 

A. operationsp, us = { <x, y, z> | z « x ♦ j } 



Quotes have been used to emphasize that the first four sets contains names (strings) rather than 
the sets they denote. Note that an algebra is a labeled tuple, and that we are using a dot 
notation similar to that used for the components of records in PASCAL to refer to the 
components of the tuple. If /f.arglength - n, ^.argtype -a, A.lc - t, /f.rlength - m, and 
A. rtype - r, then: 



niquotient) - 2, 

a(quotient, I) - a{quotient, 2) « "int", 
tiquotient) •= { normal, zero_divide }, 
m(quotient, normal) - I, 
m(quotient, zero_divide) - 0, and 
Hquotient, normal, I) - "int". 
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In the specification language described in Chapter 4, we will describe the type information for 
an operation in a compact syntax illustrated belowlbra^fMf^ operation. 

quotient: int x int — * < normal : int > ♦ < zerojdivide : > 

The range of an operation, which is a disjoint union, Is wrtlwn a* the sum of the components 
for each termination condition. The compoheliE o^tl foiii tt^ h 

written as < T : R r >, where the twrmaf component' may be abbreviated by dropping the angle 
brackets, the colon, and the condition name. 

The reader should note that termination co nd it to ni and data objicts are htated In 
different ways, and that the inputs to an operation are always ordinary data objects; which are 
never used to represent exceptions. In previous work on specifying data abstractions with 
exceptions, exceptions were modeled as distinguished exception objects, which were either 
elements of extra phyla [10] or distinguished subsets of the ordinary phyla 18). We have 
followed [43] in introducing explicit named termination conditions, maintaining a distinction 
between termination conditions and date objects, since we feel that this approach provides a 
more coherent and disciplined view of the exceptions associated with a data abstraction. 

2.4 Time Dependent Behavior 

Many programming languages have data abstractions with data objects , whose 
properties may be changed. Two common examples are records in PASCAL and arrays in 
extended LISP. Since data abstractions with time dependent properties are in fact widely used, 
it is important to develop a formalism suitable for specifying their behavior. 

An operation is non-functional if it is possible to invoke the operation with the same 
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arguments at two different times and get two distinguishable results. A data abstraction 
exhibits time dependent behavior if it has at least one non-functional operation. Data 
abstractions with time dependent behavior will be modeled as stale machines. A state machine 
is a special kind of exception algebra containing a distinguished phylum of system state 
functions. The progression of time in a computation is represented by the sequence of system 
states of the state machine 5 

We distinguish two kinds of time dependent behavior. If an operation changes the 
properties of an existing data object, we will say that the operation mutates the data object. If a 
data abstraction has no operations that mutate any data objects, then the abstraction is 
immutable, and otherwise it is mutable. If every invocation of an operation returns a data object 
that is distinguishable from all data objects that have been computed previously, we say that 
the operation creates a new data object. If a data abstraction has no operations that create new 
data objects, then the abstraction is static, and otherwise it is dynamic. It is possible for a 
dynamic data abstraction to be immutable, as illustrated by the unique id abstraction described 
in Chapter 4. 

Mutable data abstractions are usually dynamic, since the possibility of sharing data 
objects goes hand in hand with the need to create new data objects. A change in the state of a 
mutable data object is visible in all contexts in which the data object appears. If all of the 
contexts in which a given data object is used are not known, as is often the case in a program, 
then the data object cannot be mutated without risk of violating the assumptions made about 



5. We are relying on our assumption that a computation is a single sequential process. The 
history of a parallel computation has been described as a partially ordered set of local states in 
[551 
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the data object in some of the other contexts in which it may appear. A newly created data 
object is known to occur only in the context in whkh it was created, and can therefore be 
mutated without risk of interfering with other parts of the program. 

Data abstractions that are mutable or dynamic will be modeled as state machines, since 
they exhibit time dependent behavior. Data abstractions that are, both static and immutable 
can be modeled as exception algebras without introducing states. The rest of this section is 
concerned with state machine models. 

2.4.1 Data Object* vs. Variables 

In the early work on abstract data types, abstract data objects were treated as 
immutable values, and all changes of state were identified with assignments of new abstract 
values to program variables. This point of view is now widely held, and is often taken for 
granted in work on specifications for data abstractions. However, as clearly stated in Hoare's 
pioneering paper [18], this approach is not suited for describing programs that manipulate 
pointers, or more abstractly, for describing mutable data abstractions that allow sharing of 
mutable data objects. 

The distinction between the assignment of new values to variables and mutation of 
data becomes important in cases where mutable data is shared (several variables denote the 
same data object). Consider the example from LISP illustrated in Figure I. Suppose that 
initially the value of the variable x is the list (3) and the value of the variable y is the list (4 5). 
The assignment (setq x y) will change the value of * to be the Hst (4 5) which is identically the 
same Hst as the initial value of y. This assignment has not influenced the properties of the lists 
(3) or (4 5), and therefore has not affected any other variables whose values happen to be the 
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Figure 1. Shared Mutable Lists 
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same lists as the original values of x or y. If we now modify the list x by executing the 
operation (rplaca x 7), we will have changed the first element of the list x to be 7. Both x and y 
continue to denote the same list (the original value of y), but the first element of this list has 
changed, so that the value of either x or y would print out as (7 5). Whenever a data object is 
modified, that change is visible in all variables that denote the data object, and in all other 
data objects that refer to (or "contain") the modified object. 

The classical approach of associating all changes with the variables does not work 
very well in cases where mutable data is shared. If we were to insist that list values be modeled 
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as immutable sequences, and that all changes be described by assigning new values to the 
variables, then we would have a situati o n where xrplaca operation could change the values of 
arbitrarily many variables, depending on bow the data was shared. By associating states with 
the data objects themsHves rather than with the variables, we can overcome this difficulty, since 
changes can be localized in an object centered description. An example of a description of a 
mutable data structure with shared subcomponents can be found in Section 2.4.4. 

The treatment of potentially shared mutable data has been one of the major goals of 
this work. Our approach is most closely matched to object oriented languages such as CLU 
and LISP, and- our -work is more or less applicable to languages with pointers and heap 
allocation, such as Euclid, Algol 68, and PL/I. We treat operations as functions that take a 
system state and some data objects, and produce a new system state and some^dal* objects. ; TThe 
variables of the how progtammlng language do not expKcitty enter into our treatment, and we 
leave a discussion of the assignment of data objects to variables to the definition of the host 
programming language. Our treatment is directly ap pli c a bl e torthe programming language 
CLU. in which the invocation of an operation Or procedure may change the properties of sdrne 
data objects, but is guaranteed not to disturb the association b et w e e n Variables and data objects. 
For host programming languages where the invocation of * procedure may alter the association 
between variables and data objects, as in (impure) LISP, Euclki, Algol 68, arid PL/I, a 
correspondence has to be made between the operation* of the language and the operations of 
the abstract model for each data abstraction. 

There are two ways of incorporating abstractions with operations that assign to their 
input parameters in our framework. Oneway is to consider the abstractions to be immutable, 
with operations that return vectors of values to be assigned to the output variables of the 
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procedure. Another way to model such operations is to consider the L-values Ccf. 50] of the 
variables to be part of the data object rather than the variable, and to treat the data abstraction 
as mutable. 

The first approach is well suited in cases where there is no sharing of mutable data. 
Aliasing can in fact introduce sharing between the formal parameters of a caM-byreference 
procedure, so that special care is required in cases where the same variable is passed in more 
than one argument position [171 

In order to describe data objects whose properties are subject to change, we will 
introduce a system state function, which maps each data object into its properties in the current 
state. Only the permanent properties of a data object are represented by the interpretation of a 
data object in a state machine model, while the properties of a data object that are subject to 
change are represented by the image of the object under the' system state function. For most 
mutable data abstractions, the only permanent property of data object is its identity. 

2.4.2 State Machines 

Mutable data abstractions are modeled as state machines, which are defined formally 
below. A state machine is an exception algebra with a distinguished phylum of system states. 



Definition 4 State Machine 

A state machine is a tuple < phyla : P, operations : F, statcfunctions : X, states : A, 
arglength : n, argtype : a, tc : /, rleneth : m,, rtype : r, jypenames : A, ppnames : fl, 
tcharnes : T, statehames : 5, ss : s, pt : D >, where P - { P a | or c A } is ah indexed set 

of phyla, and where F » { Fg,\0 c B | is an indexed set of operations, such that 

each operation in F is a function 

F : ^ — < P a(fi, I) * • • * P a 0, *(0)> ~» ", * U * R T ■ » T < «® »'* 

where U denotes the disjoint union operation, and where 

R T - P r<0. T, 1) x x P r(0, T, m(0, T))- 2 - { Z a I « < S } and 
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£ - { A a |ac 5 } are indexed sets Mich that each 0" c £ a is a state function 
°cf p <* ~* &*r W ,ff < r\ the* ff <«*U4i*£N»*K34c:£tar*: somrq^t ^<r 
»:a-»H«:Bx«-»|r:B-> P(r), m:8xT-*ll,r:Bxrx»l-*ylare 
functions such that n0) is the number of arguments for FtffX) for any system "ifift^ 

cr, a(0, k) is the type index for the Jt-th argument of r JFjjpX tUffijs the wt of all 
termination conditions that may result from FMff), my5. T) is the number of data 
objects wturped by fitf&) to the termination tondJtioo T, WftJMitf,' *. *) is* the type 
index for the A-th return vahie of Fdtr) hi the termination condition T. 4 is the set 
of type names, is the set of operation names, f is the set of termination condition 
names, D £ A contains the names of the principal types, S fc.4 cp^t|^^ f fla*ne%o| n . 
the types that have a corresponding set of state functions, and s c (AS- D) is the 
distinguished phylum of system statei NU4rrt set qf natural number j. , 

The phylum of system states P, contains all pouible system stale funtuofw, one of which 

represents the current global state. A system spite function is the disjoint union of all the 

Individual state functions, each of which represents the current state ,pf Iffne *|pe wjth, Ufp§ 

dependent behavior. The disjoint Uf^on ^tjp^p^p^^j.^^t^ jy, where 

ft d i~^ r t> J $ a (un^'pn ■ ./: U M|!U 5 . 1 1.^ u U* |fi> ||) riiM^ J** 1 wbwver 
x c U f rf f I i c I } and x - < i, j >, /x) «//?)• Informally, the elements of the domain of the 
system state function are tagged with the name of the phylum they came from, so that the same 
set can be used to represent many different phyh without (^u^. any interfw the 

various components of the system state function. TJNe sets 2 a and A^ are jthe domains and 
ranges of the individual state functions, and hence are used in the construction of the phylum 
of system states P y but they are not themselves phyla off he state machine, reflecting the fact 
that none of the operations of the state machine Me individual state functions of individual 
data stages as arguments. The set of statenwnes 5 specifies which iprryfe represent mutable 
types. Individual state functions are associated onry with the> muteble types, of a data 
abstraction. 
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The operations of the state machine are curried, 6 so that formally an operation of a 
state machine is viewed as a family of operations parameterized by the current system state. 
This structure is introduced because the system state is qualitatively different from the other 
arguments of a typical operation, and because this structure makes corresponding notations for 
state machines and exception algebras more uniform. The operations of any immutable 
subordinate types are extended to take the system state as an extra argument, and to return the 
unchanged system state as an additional return value (the first component of the tuple of return 
values). 

Each operation of a state machine takes the current system state as its first argument, 
and when supplied with the rest of its arguments the operation produces the new system state as 
its first return value. The reason for making the global state an argument to each operation of 
a data abstraction, rather than just the state function of the principal type, is that the operation 
may depend on or modify the state of some subordinate type. A common example of this kind 
of behavior is the print operation of a data abstraction, which modifies an output stream, but 
which usually does not affecfthe state of any data object belonging to the principal type. 

If none of the principal types of a data abstraction has an associated phylum of state 
functions, then we will say that the abstraction introduces no mutability. An abstraction that 
introduces no mutability may still exhibit time dependent behavior, and hence require a state 
machine model, if it has some operations that depend on or modify the state of some 
subordinate type, or if it has some operations that take or return mutable data objects. 



6. The process of abstracting from a function with n arguments to a higher order function 
which takes one argument and returns a function of n-l arguments is named after Haskell B. 
Curry [3]. 
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2.4.3 Mutation of Data Objects 

In a state machine, the properties of a data object may depend on the current system 
state. Typically the objects of a mutably type are modeled as token* w»thc*u <a*y attributes 
except for their identity. The purpose of the state function U to associajt the current data state 
of each data object with that object, sq • that the samjf^ob^ct can have different properties to 
different states. The set of data states A ffl for the type a is the raoge of any indtvkitiai rta«e 
Function tr c S a for that type. The data state of a mutable object is roughly analogous to the 
representation of an immutabte object in an exception a^ebra. In aa exception algebra model, 
the properties of a data object are computed in terms of some represen.tagoa stn»c£ure. wbtfeto 
a state machine model, the properties of a daia object are computed in t«rms of the 
representation and its images under the state functton. 

A very simple example of a mutable data abstraction is |h« integer cell. An iniege* 
celt is a unit of memory that can store an imegcr vakie. A model for integer cells can be 
constructed by using the natural numbers for ^jf,*™ cefl and the integers f r A^^, ^| 
since the only observable property of a cell that is subject to change is the identity of the integer 
currently contained in the cell. The system state function a maps every natural number 
representing a cell into the integer Jhat is the current contents of that cell. There ate three 
operations on integer cells: create, fete A, and store. The treaty operation create* a new cell with a 
specified integer as its initial contents. (The creation of data objects is discussed in Section 
2.4.5.) The fetch operation applies the state function to the cell to get its current contents, and ■ 
the stare operation produces a new system state that differs from the oH one only hi mapping 
the updated cell into its new contents. A language for specifying models is defined in Chapter 
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4, and a number of complete examples of models for mutable data abstractions can be found 
there. 

2.4.4 Sharing of Mutable Data 

From the point of view of this work, the existence of sharing relationships among 
immutable data objects is not externally observable, since we are concerned only with the results 
of a computation, and not with the time and space requirements for performing the 
computation. A specification of an immutable data abstraction can therefore be constructed 
without considering potential sharing relationships Sharing relationships among mutable data 
objects are often externally observable, so that they must be described in a state machine model, 
at least to the extent that they influence the externally observable behavior of the abstraction. 

To reflect possible sharing relationships, the set of data states is allowed to overlap 
with the phyla of a state machine, so that the data state of an object x may be or may contain 
another object y that lies in the domain of the system state function, and therefore has a data 
state of its own. This kind of modeling structure is indicated whenever the object x has a 
potentially shared subcomponent y, such that the state of y is subject to change and such that 
the externally observable behavior of x depends on the state of y. 

In the general case, the behavior of a data object x may depend on an indefinitely 
large set of data states, which are reachable from x by repeatedly applying the current system 
state to x and to components of other data states already in the set. We will call this set the 
reachability closure of the object x. For data abstractions where there are no externally 
observable sharing relations, as in the integer cell example, the set of data states should be 
chosen to be disjoint from the domain of the system state function, so that all of the state 
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information is reachable by means of a single application of the system state function. 

Mutable binary graphs are a classic example of a data abstraction where sharing 
relationships are important. This abstraction has. operations tor creating the, pjifl graph, for 
creating a composite graph with given left and right subgraphs, for extracting the left and 
right subgraphs of a composite graph, for modifying the left and right subgraphs of a 
composite graph, and predicates for testing if a graph is empty and if two graphs are identical. 
One way to construct a state machine model for binary graphs is to take fbirwry graph to ** 
the set of natural numbers H, and A D j nar y grapn to be the disjoint union null U(Nx M). The 
data state of a graph is either null, indicating that the graph Is empty, or it is a pair of natural 
numbers representing the left and right subgraphs. An illustration of a system state a 
containing a number of overlapping binary graphs is shown in Figure 2. Note that the graph 
represented by the number 4 is a subcomponent of the graphs I and 2, and is therefore shared. 
Binary graphs can also contain cycles, as shown by graph 5, which is its own left subgraph. 

The mutation of shared data is a phenomenon that has been avoided in most existing 
work on specifications for data abstractions. As the example in Figure 2 indicates, it is not 
difficult to describe shared mutable data once we adopt a point of view centered on data objects 



Figure 2. Shared Binary Graphs 
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nither than on variables. Some of the issues involved m reasoning about shared mutable data 
will be discussed in Chapter 5. tj 

2.4.5 Creation of Data Objeots 

The principal type of a data abstraction js a fixed set for both static and dynamic data 
abstractions. For a dynamic data abstract^ the principal type is the set of aH data objects of 
the given type that can be created by any finite computation in terms of the primitive 
operations of the data abstraction. 

The population of :.-a. dynamic data abstraction <* in a system state ff Is the set of ad 
objects of the principal type of d that exist in the state (r. The concept of a population is 
meaningless for static, data abstractions §ines «*e fin* it convenient to work with total 
functions, we adopt the convention, that the: data staje of any object that harnot been created 
yet is the special object undefined, which is a member of every phylum of the state ma cblne. 
All operations of the state machine are implicitly extended to apply to this extra object by the 
following strictness requirement: 

Vi [ I < i < n 8c x t - undefined =>y(x| x n ) - undefined ] 

for any operation / taking n arguments, for any a i.fc We also adopt the convention that 
cr(undefined) * undefined for every system state <y ( 2 



Definition 5 Population of a data abstraction. 

The population of the daU abstraaion ri in the system state a is defined to be the 
set { x c P d \ <r(x) * undefined }. 

We will assume that in the initial system state every mutable type has an empty 
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populalion. and that objects are added to the population as they are created. We willaiso 
assume that every data object must be computed (i.e., returned as the value of some operation) 
before it can be used as an argument to a subsequent operation. 

We would like any program we can write in terms of the primitive operations of a 
date abstraction to be guaranteed to return only data objects with a wefT defined state, and we 
will call a data abstraction i«cur« if it has this property. 

Data abstractions with operations that w^HeiHy destroy data objects can be modeled 
readily in our framework, by having the operation change the stafe of the data object it is to 
destroy back to the original value under m»o\ thus removing it from the current population. 
Data abstractions with operations that explicitly destroy data objects cannot be secure, because a 
computation that creatra an object, destroyslt, and then applies anf Wrtber operation to it will 
produce undefined as a value; The problem of deciding when it fe safe to explicitly destroy a 
given data object must thus be addressed anew for each program that uses objects of an 
insecure data abstraction. This is known as the dangling reference problem, and it Is generally 
acknowledged to be difficult. 

We will concern ourselves mostly with secure data abstractions. The population of a 
secure data abstraction grows monotonically, and the reachability closure of any object in the 
population of a secure data abstraction win never contain the data object undefined. 

Informally, we will say that a model is rtductH if tt does not contain any unnecessary 
data objects. (A more careful definition of a reduced model can be found in Section 3.3.) The 
standard model of a data abstraction should be minced, since this generally leads to a cleaner 
specification. In the context of a state machine model, this means that an operation should 
extend the population only when it creates a "new" abstract object. An abstract object is "new" 
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if it is distinguishable from every object in the old population by means of some finite sequence 
of operations. In practice the required sequence of operations is often very easy to find, since 
many dynamic data abstractions provide an equal operation which can be used to test if two 
abstract objects are identical. 

A very simple example of a dynamic data abstraction is the unique id abstraction, 
which has only two operations, create and equal. The create operation creates new unique ids; a 
newly created unique id is unique because it is guaranteed to be distinct from all previously 
created unique ids. The only way to create a unique id is by means of the create operation. 
The equfl-l operation is provided as a means of comparing unique ids, and it is guaranteed to 
distinguish a newly created unique id from any previously existing unique id. Unique ids are 
immutable (so that they cannot be forged or tampered with - one application for unique ids Is 
in implementing capability based data protection schemes). 

This example illustrates that there is a state change associated with the creation of a 
new data object, as reflected by the increased size of the population, even though the properties 
of all previously existing objects may be unchanged. Note that the create operation is not a 
function of its arguments unless the state is explicitly included as an argument to the operation, 
because it will return different unique ids in different states, and it will never return the same 
one twice. 

Another example of a dynamic data abstraction is the impure list abstraction (as found 
in LISP), with the operations cons, car, cdr, atom, equal, eq, rplaca, and rplacd. Each time it is 
called, the cons operation constructs a new list, which is distinguishable from any previously 
existing list by means of the eq operation. The impure list abstraction is also mutable, because 
the rplaca and rplacd operations can be used to modify the contents of existing lists. These 
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operations can also be used to distinguish a newly created list from a previously existing list 
with the same contents, by modifying one of the lists and looking to see if the other is changed 
also. If the lists are distinct, then one will be changed and the other will not be. Thus the 
impure list abstraction would be dynamic even without the «f operation. In the general case, 
two abstract objects are identical only if they have the same observable properties in the current 
state, and if they are guaranteed to have the same properties in all subsequent states. 

Consider a restricted kind of list, which has the same operations as the impure lists of 
the previous example, except for eq, rptaca, and rfdocd. This list abstraction is immutable, and 
also static, because there is no way to distinguish the list returned by one invocation of cons 
from that returned by a later invocation with the same arguments. This example demonstrates 
that whether or not a given operation returns a new abstract data object depends on the other 
operations of the abstraction. It may require a bit of thought to decide if a given data 
abstraction is in fact dynamic, and hence requires a state machine model, or if it is static and 
immutable, and hence should be specified by an exception algebra model. 
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3. Denotations for Data Abstractions 

The meaning (or denotation) of a data abstraction is the class of all models of the data 
abstraction. In the axiomatic approach to specifying data abstractions, this class is taken to be 
the class of all models satisfying a given set of axioms. In the abstract model approach, the 
class of all models of a data abstraction is taken to be the set of all models with the same 
observable behavior as a given model, which is explicitly constructed. 

In this work, we will assume that a model for a data abstraction is an exception 
algebra. We will say that a model is dynamic if it has a distinguished phylum of system states, 
and that it is static if it does not. 

3.1 Complete and Partial Models 

A model for a data abstraction rf is complete if and only if d has interpretations for the 
types and operations of d and of every data abstraction subordinate to rf. The externally 
observable behavior of d is characterized by the finite computations in terms of the operations 
of rf and the abstractions subordinate to d, and any such computation can be interpreted in a 
complete model for rf. A partial model for rf may leave some of the abstractions subordinate 
to rf uninterpreted. 

Since the identities of the objects in a model are not a priori observable, there may be 
no way to compare the results of a closed computation in two different models. This problem is 
resolved by insisting. on a unique standard model for the booleans, containing exactly two 
boolean values, so that the results of any computation producing a boolean value can be 
compared for any set of models. To reduce all comparisons of results to the problem of 
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comparing boolean values, it is necessary to Include the operations of the subordinate 
abstractions in the computations. Thus complete models are required to make sure that every 
computation of interest can be interpreted. 

In practice, a system of data abstractions is described incrementally, by giving a partial 
description for each abstraction (or set of mutually subordinate abstractions) rf in the system. 
The partial descriptions give a prescription for constructing interpretations for the principal 
type and operations of rf, assuming that complete models for the abstractions subordinate to rf 
are already defined. In particular, the interpretations of the subordinate types of d are to be; 
taken from the models for the defining abstractions of those types. The construction of a 
complete model for d is described more precisely below.' 

Let rf be a data abstraction, let rfj , .... rf R be the abstractions subordinate to rf, and 
let m i be a complete model for d t for each i in the range I < I < n. Suppose we have a partial 
description D for rf, which gives the signature of rf, the name of the principal type of rf, and 
Interpretations for the principal type and operations of rf. If D describes an exception algebra, 
then a complete model m for rf is constructed as follows. 



w* phyh - D. phyte D . ^ U ( ^U ^ w f . phyb w ., p, ) 

m. ops - D.ops U( U m,. ops) 
\<i<n ' 

m. arglength - D, arglength U ( U m^. arglength } 

m. argtype, m. tc, m. rlength, and m. rtype are similarly defined as disjoint unions, 
m. typernmes - P. typenamestt ( U w ( ..ty p e nam e> ) 

w. opnames - D. opnames U ( U ra^. opnames) 

m. tcnames ■ D. tcnames U ( U m,. tcnames ) 

l<i<n '. 



I. The details of this construction are not essential for an understanding of the rest of this 
work, and may be skipped on a first reading. 



-45- 
m. pt = D. pt 

where U denotes disjoint union and where U denotes ordinary set theoretic union. If D 
describes a state machine, then the above relations still apply, and we have to add the following: 

m. statefunctions = { D. statefunctions^ t } U { m r statefunctions m # 1 1 m i is a state machine } 

m. states = { D. states D# t } U { m.. states m # , | m i is a state machine J 

m. statenames = D. statenames U ( U { m t . statenames I m f is a state machine J ) 
m. ss = D. ss 

n ' P n y ,a m. ss = I u ! a a I a c S } I a ct ( 2 a for each <* c S J 
where 5 = m. statenames and S = m. statefunctions. 

In the rest of this Chapter, we will limit our discussion to complete models, and we will 
frequently leave out the qualifier "complete". 

3.2 Behavioral Equivalence 

Informally, two models are behaviorally equivalent if they have the same externally 
observable behavior. In this section we develop a precise mathematical definition of an 
equivalence relation that captures this informal notion. We define closed computations, and the 
interpretation of a closed computation in a model. Two models are behaviorally equivalent if 
they contain interpretations for the same types and operations, and if the value of any finite 
closed computation in one model is indistinguishable from the value of that computation in the 
other model. 

Behavioral equivalence is an important notion, because it is the basis for defining the 
correctness of an implementation of a data abstraction. An implementation defines a model for 
the abstraction it implements, and the implementation is correct if the model it defines is 
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behaviorally equivalent to the model that specifies the abstraction. 

We can meaningfully compare two models only if they have interpretations for : the 
same types and operations. Two models can be behavkwaHy equivalent only if they have the 
same signature. 

Definition 6 Signature 

The signature of an exception algebra a is the tuple 

< a rg length : a. arglength, argtype : a. argtype, 

tc : a.tc, rlength : a. rlength, rtype; a.rtype, 

typenames : a.'typenames, opnames : a. opnames, tcnames : a. tcnames X 

If two exception algebras have the same signature, then they have the same names for the 

phyla, operations, and termination conditions, and corresponding operations have the same 

numbers and types of arguments, the same set of possible termination conditions, and the same 

numbers and types of return values in each terminalio»4ondition. iA* a matter «f nbtattenal 

convenience, we require comparable models to be indexed by the same sets, so that 

corresponding types and operations have the same names, and we can talk about the 

interpretations of the same operation name in several different models. 

In order to characterize the kinds of behavior a data abstraction may exhibit, we 

define the set of closed computations. 

Definition 7 ; Closed computation 

A closed computation with respect to a signature S is a finite sequence of pairs € 

such that 

Cti) * <«p :/, args : s > for each* in the range I £ i £ lengtMC), 

where/ c S. opnames. and s is a sequence of argument specifications such that 

length(j) « S.argkntbtyX 

slj) - < step : n, tc : T, result : k >, (the source of the /-th argument toy) 

I < n < t, (n is the index of a previous step of the computation) 

T c 5 . tc(C[n]. op), (T is the required termination condition for step n) 
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1 < k < S. rlength(C[n]. op, t), (the Hh object returned by step n must exist) 
and S. rtype(C[n]. op, T, k) - S. argtype(/, ;) (and it must have the right type) 
for each j in the range 1 < j < length(j). 

A closed computation is a sequence of steps, where each step is the application of some 
operation of a data abstraction to data objects resulting from previous steps. Every 
computation starts from nothing, and computes data objects as it proceeds. A closed 
computation is analogous to an uninterpreted flowchart, since the sequence of the operations is 
given, but the operation names are left uninterpreted. A step is a pair consisting of an 
operation name and a sequence of argument specifications. An argument specification is a 
triple, which specifies a previous step, a required termination condition for that step, and the 
index of the desired result. The index is necessary because an operation will in general return 
more than one object, and we have to say which of the returned objects to use. Since the 
number and types of objects resulting from an operation can be different for different 
termination conditions, an argument specification requires the step producing the argument 
object to terminate in a particular termination condition, so that we can be sure that the 
specified data object is of the proper type. A closed computation can fail to have an 
interpretation in a given model, if the termination conditions actually computed do not match 
the required termination conditions in the argument specifications of the closed computation. 

An example of a closed computation CI over the list abstraction of pure LISP is shown 
below. 



Cltl] - < op : nil , args : <> ) 

Cl[2] - < op : cons , args : < < step : I, tc : normal, result : I >, < step : 1. tc : normal, result : I > > > 

Cl[3] = < op : cons , args : < < step : I, tc : normal, result : 1 >, < step : 2, tc : normal, result : I > > > 

This computation computes the value of the LISP expression "(cons nil (cons nil nil))". 
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A closed computation consists of a finite sequence of operations. With no conditionals 
or other control structures, and can be thought of as a trace of the execution of some program 
that uses the operations of the data abstractions of interest The finite prefixes of the history of 
any program can dearly be described by a set of closed computations, and any finite closed 
computation can be described by a program in ftst about any programming language. Note 
that a machine for executing closed computations requires an unbounded amount of memory, 
because It "Is assumed that meiresuts of each step are saved, and may be used In any number of 
succeeding steps. 

We want to know whether or not there is some computation that yields observably 
different resute when interpreted m each of the two models whose behavior we are comparing. 
Ft is sufficient for this purpose to consider only me finfte computations: given two infinite 
sequences, if we know that their prefixes of length » are the same for every natural number n, 
then the original infinite sequences must be the same as welt. 

The interpretation of a computation in a given model is the sequence of results 
obtained by applying the interpretations of the specified sequence of operations in the model to 
the specified arguments. Since the interpretation of an operation is different for static and 
dynamic models, we wilt give separate definitions for the interpretation of a closed computation 
in each kind of model. 



Definition 8 Interpretation of a Computation in a Static Model 

Let M be an exception algebra model, let F - M. operations, let n .- Af . arglength. let 
C be a closed computation with respect to the signature of M , and let I be a 
sequence I is the interpretation of the computation C in the model M if and only if 
all of the following conditions hold: 
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1. length(I) = length(C), 

2. For each i in the range 1 < I < length(C), 

IM ' f r 0(x i , ... , x n (Q) ), where C[i] = < op : 0, args : s >, 

3. For each j in the range I ^ j ^ n(j8) 

Xi = obj(IUl) [w], where s[j] «= < step : k, tc : T, result : w >, and 

4. tc(IU3) - T. 

A computation is a sequence of operation names and argument specifications, and the 
interpretation of a computation in a model is the sequence of values obtained by applying the 
interpretations of the specified operations in the model to data objects specified by the argument 
specifications. The set of operations of a model is indexed by a set of operation names, and the 
indexing function specifies the interpretation of each operation name in the model. Since an 
operation may return more than one data object, the interpretation of a computation is a 
sequence of tuples of data objects, injected into the component of the disjoint union 
corresponding to the termination condition produced by the operation. Recall that the range of 
each operation of an exception algebra is a disjoint union of a set indexed by termination 
conditions. Each element of a disjoint union is a pair, containing a tag and a data object. If y 
is the result of some operation of an exception algebra, then obj(y) denotes the object without 
the tag, and tc(;y) denotes the tag, which is the name of a termination condition. 

The interpretation of the computation CI (shown above) in the usual model of pure 
LISP is the following: 



II [1] - < normal, < nil > > 
II [2] - < normal, ((nil))) 
II [3] - < normal, < ( nil nil ) ) ) 



The pairs stemming from the disjoint union are shown explicitly. The first component of the 
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pair is the tag (termination condition), and the second component is the sequence of data objects 
resulting from each operation. Since all of tfie operation* shown in *his example return a single 
value, the resulting data objects are contained in sequence* of length one 

Note that the termination condition of each step must match the termination condition 
required by every argument specification that uses the results of that step. A closed 
computation may or may not have an interpretation in a model If an interpretation exists, it Is 
unique, because the operations of a exception algebra are functions, which necessarily have 
unique values. A computation may fail to have an interpretation in a given model because the 
operation specified by some step of the computation may terminate in a different condition than 
the one required by some later step that uses the results of the given step. If several steps of a 
computation make conflicting requirements on the termination condition of a given step, then 
that computation will not have an interpretation in awf model of the abstraction. If a 
computation has an interpretation in a model, we wiH say that the computation is feasible in 
that model. A feasible computation can involve steps with exceptional termination conditions, 
and it is possible for the termination condition of the final step to be normal even if the 
termination conditions of some intermediate steps are exceptional. 

The interpretation of a closed computation in a dynamic model is similar, except that 
there is an extra component containing the system state Recall that the first argument and the 
first return value of every operation of a state machine is a system state. 



Definition 9 Interpretation of a Computation in a Dynamic model 

Let M be a state machine, let F = M .operations, let n - Af.argfcngth. let € be a 
closed computation with respect to the signature of M, and let I be a sequence. I is 
the interpretation of the computation C in the model M if and only if all of the 
following conditions hold: 
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1. length(I) = length(C), 

2. For each i in the range I < i < length(C), 

Mi] = FfiiVi) (*| x n{0) ) ' where 

C[i] = < op : (9, args : j >. 

cr i = A x . undefined if i = I 

cr f = objdfj - I]) II] if i > I 

3. For each j in the range I < j < n(Q) 

Xj - obj(IU]) [w * I], where s[j] = < step : *, tc : T, result : w >, and 

4. tc(I[A])-T. 

The initial state for any computation sequence is the empty state, which maps every data object 
into the initial data state undefined and thus has an empty population (i.e., no data objects 
have been created in the initial state). Each step of a computation except for the first step starts 
with the state produced by the previous step. The interpretation of a computation in a dynamic 
model is a sequence of tuples, whose first component is a system state, and whose remaining 
components are the tuples of data objects and the system states produced by the operations 
specified by the closed computation. Since the first return value of an operation of a state 
machine is always a system state, the w-th data object returned by an operation of the abstract 
type corresponds to the (w+l)-st component of the sequence of values returned by the 
interpretation of the operation in the state machine. 

If a computation has an interpretation in a given model, then the value of the 
computation in that model is the result of the last step of the computation. 



Definition 10 Value of a computation 

If the computation C has the interpretation I in the model M, then the value of C in 
M is obj(I[length(II)]) if M is a static model, and the value of C in M is 
< y[2] , ... , y[!ength(v)] > where v = obj(]I[length(K)]) if M is a dynamic model. 

Note that the value of a computation can be a tuple containing more than one data object. The 
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final state of the interpretation of a computation in a state machine is not part of the value, 
since it is not directly externally observable. --..'.■« i 

We are now ready to define behavioral equivalence. 

Definition 11 Behavioral Equivalence of Models 

Two models Afl and Af2 are behavwraHy equivalent if and only if all of tb« 
following conditions hold: 

1. Ml and Af 2 have the same signature 5. 

2. for any finite closed computation C with respect to the signature S, C has an 
interpretation in Afl if and only if it has an interpretation In Ml. 

3. For any finite closed computation C with respect to the signature 5. C has an 
interpretation in *ft and the value of C mAfris f the boolean value r if and only if 
C has an interpretation in Af2 and the value of C in M2 is the ***** boolean 

valuer. ' ! ■.:-,■■■';■■ ':>-.;• • >".:.; r: -•■;<-,..■ v. ; . 

Two models are behaviorafry equivalent if they have the same signature, interpretations for the 
same set of closed computations, and if every computation resulting in a boolean value has the 
same value in both models. 

Theorem 1 : Behavioral equivalence is an equivalence relation. 

Proof : The theorem follows difectly from the definition. 
End of Proof 

We intend two models to be behavioraHy equivalent if and onb) If they have the same 

externally observable behavior. In practice, what we can really observe is the output of a 

program, which is usually manifested as characters printed on a piece of paper, or displayed on 

a terminal. Although there is a wide variety of peripheral devices that can be connected to a 

computer, capable of producing a wide variety of observable effects, they can all be modeled by 

a (mutable) output stream data abstraction sufficiently well for bur purposes, since we are not 
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concerned with the actual physical properties of the output, but only with whether or not two 
outputs are distinguishable. We model the data states of an output stream as finite sequences of 
integers (which can be interpreted as character codes in most cases). We assume output streams 
have an operation that returns the current state of the stream, represented as an immutable 
sequence of integers. This operation models the system user, who observes and compares the 
actual outputs of the system, and it need not actually be implemented. It is included because 
some data abstractions have properties which can affect the printed output, but which cannot 
be tested by another program. 

Integer sequences are defined to be a priori distinguishable because they are used to 
model physically observable outputs of the system. Note that the states of mutable data 
abstractions other than output streams are not a priori observable. We will further assume that 
integer sequences have an equal operation which allows us to reduce the problem of comparing 
sequences of integers, representing states of output streams, to the much simpler problem of 
comparing truth values. 

The domain of truth values is a priori distinguishable because of our assumption that 
the host programming language provides some means of altering the flow of control depending 
on a truth value For example, a conditional statement that prints a different message on each 
arm can be used to physically distinguish between the truth values. Because of this property of 
truth values, we insist that the boolean abstraction be given the standard interpretation in all of 
the models that will enter our discussion. In the standard interpretation, there are exactly two 
truth values, T and F, with the operations and, or, not, implies, and equivalence (see Section 4.2.1 
and Appendix I). 

Different termination conditions are also externally observable, because we can 
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associate handlers that print different messages with each exception. We do not have to 
introduce any extra machinery to treat this case, because it is already covered by our definition 
of the interpretation of a computation. If the final step of a computation C results in two 
different termination conditions in two different models, then by adding one more step that uses 
the results of the last step of C and that requires it to terminate in one of the two observed 
termination conditions, we will get a closed computation C that is feasible in one model but not 
in the other. 

In our definition of behavioral equivalence, we have assumed that all of the aspects of 
the behavior of a data abstraction can be observed by means of the operations of the 
abstraction and its subordinate abstractions. If every operation of every abstraction in the 
system computes results that depend only on the data objects explicitly passed in as arguments 
or on the data states in the reachability closure of the arguments (see Section 1.3), then this 
assumption is justified. An example of a system that violates this assumption is the following. 
Suppose that the abstraction NASTY has an operation count that returns a natural number 
representing the number of objects of type NASTY that have been created so far, and that the 
only operation that creates new objects of type NASTY is the nuHary create operation.. In order 
to implement this behavior, the create and count operations must share some own data. If some 
other abstraction A in the system is implemented using a representation containing a object of 
type NASTY, then the operations of A can have effects which are only observable by means of 
the count operation of NASTY, even though NASTY is not necessarily subordinate to A (i.e, 
A need not have any operations that operate on or return any objects of type NASTY). In 
general, abstractions with state components that are associated with the type as a whole rather 
than with any individual data object cannot be used to represent objects of other types without 
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introducing hidden interactions of the sort described above- Because we want the behavrdroflr 
data abstraction to be independent of the representation used in any particular implementation, 
we exclude structures fclte NASTY from our d»scu*stpn. The specif icatwn language pr^rntrd 
in Chapter 4 has been designed so that abstractions violating this locality assumption cannot be 
defined. 

3.3 Reduced Models 

Data abstractions are identified with equivalence classes of models with respect to the 
behavioral equivalence relation. In this section we will snow how to construct a representative 
element of such an equivalence class, known as a reduced model, which can be used to specify 
the behavior common to all of the members of the class. Reduced models are shown to be 
unique up to isomorphism, and they are minimal in the sense that they contain no unnecessary 
elements. Models to be used as specifications for data abstractions should be reduced, since 
irrelevant components serve no useful purpose and may lead to confusion. 

The concept of a reduced model has to be defined somewhat differently for static and 
for dynamic models. The two cases are discussed below. 

3.3.1 Reduced Static Models 

Before we can precisely define what we mean fey a reduced model, we have to 
introduce some auxiliary concepts. A reduced model should be free of "extra" objects that 
cannot influence the externally observable behavior of the model. 
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DefinttJott 12 Reachable Objects 

A data object x is rencksNe m a model M with a signature 5 if and only if there a 
some finite dosed cempefation £ with respect ta$ such thar * H the varae of C rn Af 

Only the reachable objects in the phyla el a model can Influence the externally observable 

behavior of a model 

We would also like a reduced model not to contain redundant copies of the same 

object, if there is no observable property that can distinguish between Hie copies. Tp arrive at 

a definition for the external equivalence relation on data objects, we have to define open 

computations. 

Definition 13 Open Computation for a Static Model 

An open computation with respect to a signature 5 and a type a c 5. typenames 

is a finite sequence C such that 

CU) - < op :/, args : $ > for each I in the range 2 i i < length(C), 

wbe«/<: t5. opnames. and jtfeva sequence such that 

fength(j) - S. argtenthf/), 

4/} -< Step :«. W :T, result : a >. where 

l<n<*. 

if n -I then S.argtype^.y}- a, f • normal, and a - 1, 

and if n > I then Tc5. tc(C{n]. op) 

IS*SS*rh»gti*leC«)*op,T) 

and S. rtype(Cln]. op. T, «) - J. argtypef/, fi 
for each y in the range I < j < length^ 

An open computation is just like a closed computation, except that an initial data object is 

specified, which can be used in any subsequent step of the computation, in addition to the data 

objects produced by the preceding step*. The inttnlt data objtct li a parameter to the open 

computation, and the value of an open computation is a function oTthis parameter. 

Definition 14 Interpretation of an Open Computation In a Static Model 

Let M be an exception algebra model, let F - M. operations, let n - Af .arglength. let 
C be a closed computation with respect to the typename a and the signature of M . let 
x c P a< and let I be a sequence. I is the interpretation of the computation C 
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applied to the object x in the model M if and only if all of the following conditions 
hold: 

1. Jength(I) = length(C) 

2. I[l] = < normal, < x > > 

3. For each i in the range 2 < i < length(C), 

Mi) = Ffftxi . , x„(0) ), where C[i] = < op : 0, args : s >, and 

4. For each j in the range I < j < n{0) 

Xj = obj(IM) In»], where s[j] = < step : k, tc : T, result : w >, and 

5. tc(E[A.]) = T. 

The interpretation of an open computation is like the interpretation of a closed 
computation, except that the interpretation of the first step of the computation is a sequence of 
length 1, containing the specified initial data object x, and with a normal termination condition. 
We have injected the initial data object x into the normal component of a disjoint union for 
the sake of uniformity. The < tag, object > pair is shown explicitly in condition 2. 

Definition 15 Value of an Open Computation in a Static Model 

If C is an open computation with respect to the type o and the signature 5, M is a 
model with signature S, x ( M. phyla a , and if I is the interpretation of C in M with 

respect to a, then the value of C applied to x in M is C(x) = obj(I[length(I)]). 
The value of an open computation is the tuple of data objects resulting from the last step of the 
computation when interpreted in the given model. 



Definition 16 External Equivalence of Objects in a Static Model 

Let M be a model, a ( M. typenames, and xl, x2 c M. phyla a . The the data objects 
x\ and x2 are externally equivalent if and only if for every open computation C with 
respect to a all of the following conditions hold: 

I. C has an interpretation in M with respect to the data object xl if and only if C 
has an interpretation in M with respect to the data object x2. 
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2. C has art interpretation in Af with respect to xl and the value of C applied to xl 
in Af is the boolean value t if and only if C has an interpretation in Af with 
respect to xl and the value of C applied to x2 in Af is the saine; boolean value f. 

Two objects of a given model are externally equivalent if and only if ey,ery ^pen cpoiputation 

applied to one of the objects yields a result that is indistinguishable from, the result of applying 

the same open computation to the other' object This means tinat the two objects share all 

externally observable properties, and therefor* represent the same abstract object, even if they 

are two distinct objects in the model The point is that the identities of the objects in a model 

are not externally observable unless the data abstraction provides some operation* that make 

them observable. 

Now we are ready to define reduced static models. 

Definition 17 Reduced Static Model 

A static model Af is redwed if and only if all of the following conditions hold: 

1. For each et c Af . typenames and for each x c Af . phyb a , x is reachable 

2. For each or c Af. typenames and for each xl, x2 c Af.phrla^, if xl and x2 are 
externally equivalent, then xl - x2. 

A reduced static model has no extra objects, since every object is the result of some finite closed 

computation, and hence externally observable, and every distinct pair of objects in the model 

differs in some externally observable property. 



Theorem 2 : Every equivalence. class of models with respect to the behavioral equivalence 
relation contains a reduced model. 

Proof : Take the reachable subset, and divide by the external equivalence relation. Details in 
Appendix HI. 
End of Proof 
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Theorem 3 : If two reduced models are behaviorally equivalent, then they are isomorphic 

Proof : The isomorphism maps the value of every closed computation in one model into the 
value of the same computation in the other model. Details in Appendix III. 
End of Proof 

Thus every constant data abstraction has a reduced model that is uni^e, up to isornorp hi«n 

Theorem 4 : If Af is behaviorally equivalent to Af and Af is reduced, then there is a 
homomorphism from a subset of Af' onto Af. 

Proof : The construction of theorem 2 yields a reduced model which is a homomorphic image 
of M. Compose that homomorphism with the Isomorphism guaranteed by theorem 3. Details 
in Appendix III. 
Ettil of Proof 

We can always find a homomorphism from an arbitrary static model to a behaviorally 

equivalent reduced model. This result is interesting because the classical way to prove the 

correctness of an implementation of a data abstraction with respect to an abstract model 

specification is to construct such a homomorphism front the implementation to the defining 

model. The theorem says that the required homomorphism exists for any correct static 

implementation model, provided that the defining model is reduced. While there is no 

guarantee that the homomorphism is computable or even finitely describable, the 

homomorphisms corresponding to most implementations are quite tractable. As we shall see in 

the next subsection, the corresponding theorem for dynamic models is false. 

3.3.2 Reduced Dynamic Models 

Informally, a model is reduced if it has no unnecessary objects. We have to take a 
different approach to formalizing this concept for dynamic models, because the existence of a 
data object and the properties of a data object are not completely determined by the identity of 
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the obfcct. since they will in general depend on the system state. Theorem 4 fails for dynamic 
models for this very reason. A homomorphism on a many sorted algebra is a family of 
mappings, one for each phylum. In a dynamic model, the elements of any phylum 
corresponding to the prindpl type of a dynamic data abstraction have no distinguishing 
properties except for their identity. Alt of the interesting properties of an object belonging to 
such a phylum come from the image of that object under the system state function, and any 
particular object does not have any interesting properties until it is created (ie, until some, 
operation gives the object a data state other than undefined). Depending on how an object 
gets created in each particular computation, an object in the model can come to represent any of 
a number of different abstract objects. Consequently, there may be no correspondence between 
the objects of one model and those of another which is both consistent with the operations and 
independent of the computation history. The cases where the correspondence is independent of 
the computation history are rare. 

The rest of this section consists of a characterization erf a reduced dynamic model, and 
an example of two behavior ally equivalent models such that one is reduced but is not a 
homomorphk image of the other. 

There are two requirements a dynamic model, must meet if it is to be reduced: the 
phyla must contain no unnecessary objects, and for every state, the population must contain no 
unnecessary objects. If we insist that every element of every phylum must be reachable, the first 
requirement is met. Reachability can be defined for dynamic models in a way entirely 
analogous to the definition for static models, and presents no essential difficulty. For most 
dynamic models a countable infinity of data objects are reachable, and each data object has no 
directly observable properties except for its identity, so that the first requirement is not very 
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interesting. The second requirement requires a fundamentally new approach, because there is 
no way to meaningfully define the behavior of an abstract object independently of the system 
state. 

We will assume that an operation of a data abstraction can create at most finitely 
many new data objects Icf. 15]. Since we require all operations to terminate in a finite amount of 
time, and since all real machines compute at a finite rate, this assumption is justified. A 
consequence of this assumption is that the population of every reachable state is finite, where a 
state is reachable if and only if there is some finite closed computation that produces that state. 

We can define reduced models for dynamic models as follows. 

Definition 1 8 Reduced Dynamic Model 

A dynamic model M is reduced if and only if there is no other model M" such that 
M' it befcavlora&r equivalent ^^ the 

card.nal.ty of the population of fhe final *ate pfolficld iby C WW iistrfctly smaller 
than the cardinality of the population of the final state produced by C in Af . 

An example of a case where we have a reduced dynamic model M\, and a 
behaviorally equivalent model M2 such that there is no homomorphism from any subset of Af 2 
onto Ml is described below. 

Consider a version of mutable lists, which have nil as the only atom, and for which 
the rplaca and rplacd operations return the list that was modified *athw? than the old value of 
the component that was replaced, as is the case in US®. Tne'ihodct Ml has P, jst - N, and 
^bst " 1 Ml 1 u < M x *)• ,n Mi > lhe on'y eperation th« extends the population of the fist 
domain is cons. The eq operation serves to make the identity relation on objects in the model 
externally observable, so that every newly created object is eisUnguishaWe from any previously 
existing object, and hence M4 is reduced. , 
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The model Mi has F, |st - N and A Ust - cdlt{ nil }U(Nx M)l In Af2, r/>teca and 
r^/arrf as well as cons extend the population of Py^. We have introduced an extra level of 
indirection, so that the identities of the abstract objects correspond to the identities of the cells 
that are the data states of the elements of Pj^ rather than to the elements of P^ directly, as 
would be the case for any reduced model. M 2 is behavioratty equivalent to Aft, but M2 is not 
reduced, because the rplaca and rplacd operations create redundant list objects. 

There can be no homomorphism from Mi to Ml because the correspondence between 
objects in Mi and objects in Ml depends on the system state. For example, the computation 
shown in CI below 



CIO) - (op : ni/ , ar^s : <)> 

CK2J « (op : cfins , args :«step : I, tc : normal, result :#, (step; I, tc ; normal, result j l>» 

CK3J - (op : cons , args V (<step I. tc : normal r«ul :i>, (step ; l^tc ; normal result : J»> 



has the following interpretation in Mh 

IWlJ - < (Tq . >' where ff^O) - ntf 

IIK2] - ( (T, , I > where (r^O) - »u7, and (r,(l) -( 0, > 

IIIC3J - < cr 2 , 2 > where OjW) - ntf, (T^I) - ( 0, >, and 1X$L) - (0, ) 

CI evaluates the expression "(cow stf ntif twice, resulting In two copies of the Ust («/); Each 
element of the interpretation III is a pair containing the results returned by the operation 
specified by the corresponding step of the computation CI. The first element of each pair is a 
system state function, and the second component of each pair is a natural number representing 
a mutable list. Note that the system wate is considered to be result 0, and that result I Is the 
first data object returned by the operation, corresponding to the second element of each pair. 
The computation CI has the following interpretation hi M2-. 
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Il2[l] = < cr , > where a^O) = cell-O, 

(T (cell-0) = nil 
El2[2] = < CT, , I > where 0^(0) - cell-O, <r,(l) - cell-l. 

O-,(cell-0) = nil, CT,{cell-l) - < 0, > 
112(3] = ( tr 2 , 2 ) where rr 2 (0) = cell-O, <r 2 (l) « cell-l, 0" 2 (2) . cell-2 

a 2 (cell-0) = nil, (T 2 (cell-1) - < 0, >, <r 2 (cell-2) - < 0; > 

In model M 2 we have an extra level of indirection. If the state <T Ml of Afl corresponds to the 
state a M2 of Af2. then we have the relation m (n) ~ ff M2 (Q M ^n)) for any n c N (a natural 
number representing a mutable list). The correspondence between the elements of P, jst for the 
final state produced by CI in M2 and the elements of the population of P iist in the final state 
produced by the interpretation of CI in Ml is 



Af2 Ml 

-> 

1 -> 1 

2 -* 2 



Now consider the computation C2 shown below. 

C2[IJ - <op : ml , args : <» 

C2[2] = <op : cons , args . «step : I, tc : normal, result : l>, <step : I, tc : normal, result : l>» 

C2[3] - (op : rplaca , args : «step : 2, tc : normal, result : l>, (step : I, tc : normal, result : l>» 

C2 computes the expression "(rplaca (cons nil nil) nil)". The interpretation of C2 in Afl is 

I21[l] « < (T , > where (T (0) - nil. 

I2U2] - ( 0", , I > where CT|(0) = nil. and (r,(l) - ( 0, >. 

I2I[3] - ( CT, , 2 > where (T 2 (0) - nil, and 0- 2 (D - < 0, >. - 

The interpretation of C2 in Ml is 
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1220) - < tr , > where (T^O) - cell-O, and 

ag(celH») - nil. 
122(2) « < cr, , I > where fffi) ^ceH-u, afl) -ceU-l, 

(r,(celK)) - ikl, and fr,(cerft) - < 0, >. ' 
122(3] - < (T 2 , 2 > where S2<GH(riW,ff^^ 

(TgfcdH*) - ntf, and c^ce11% - < 0, \ 

Thus the correspondence between the elements oT the population of P fjst in Af2 and the 
dements ofiP, jsl in M I required hi the final state produced by C2 is 



M2 Ml 

© -* 

1 -* I 

2 -* I 



A homomorphism must be a function, and hence single valued. Since the computations CJ and 
C2 introduce conflicting requirements for the image of the element 2 c f», |$t , there can be na 
homomorphism from Af 2 to Aft. 

This example demonstrates that there are some correct implementations whose 
correctness cannot be established by exhibiting a homomorphism from the implementation to 
the defining model, even ff the defining model h tedUced. Therefore other methods of proof 
relying more directly on the underlying concept of behavioral equivalence are needed. Proofs 
of correctness of implementation are discussed rn Chapter 5. 
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4. Specification Language 

In Chapter 3 we saw how a data abstraction could be identified with an equivalence 
class of models with respect to the behavioral equivalence relation. It is our thesis that an 
effective and useful technique for specifying a data abstraction is to explicitly construct a 
(reduced) model of the abstraction. The data abstraction denoted by such a specification is the 
class of all models behaviorally equivalent to the model that was constructed, which will be 
referred to as the standard model. In order to define a standard model for a data abstraction, 
we must specify the signature of the data abstraction, and give interpretations for its phyla and 
operations. In this chapter we present a number of methods for doing this, along with a 
language for describing particular models defined using these methods. Chapter 5 is concerned 
with proving that a proposed implementation is correct with respect to a given standard model. 

Since we are primarily interested in using our specification language for defining 
particular models, rather than for proving meta-theorems about the specification language, we 
have made no effort to keep the language minimal. Our intent was to make it easy for people 
to read and write specifications in our language. Such a goal has no objective measure, and the 
reader is urged to consider our examples and to construct additional ones in order to judge the 
merits of the formalism. The syntax and abbreviations we have chosen are meant to ease the 
task of the human reader. For applications where mechanical processing of the specifications is 
to play a dominant role, a more restricted syntactic form may be appropriate. 

As mentioned in Section 3.1, we will construct models for data abstractions 
incrementally, assuming at each stage that models for all of the subordinate abstractions have 
already been defined. We will explicitly construct the interpretation of the principal type, and 
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implicitly specify that the interpretation of each subordinate type is the principal type of the 
standard model for its defining abstraction. 

In this Chapter we wiH assume that a model for a static data abstraction is an 
exception algebra, and that a model for a data abstraction with time dependent behavior is a 
state machine. (Recall that a state machine is an exception algebra with a distinguished 
phylum of system states.) 

4 Jl Components of a Specification 

The important part of the specification, language, is its siructure and semantics, which 
are explained informally below. A precise definition of our somewhat arbitrarily chosen syntax 
can be found in Appendix IV. 

The bask components of a model specification are iBustrated bj the, example shown in 
Figure 3. This example gives a definition of immutable stacks (or stack statesX modejed in 
terms of sequences, where the top element of the stack is the last element of the sequence 
representing the stack. This example has been treated many times in the literature on 
specifications for data abstractions, and will probably be familiar to the reader. Later we will: 
see a specification of mutable stacks. The form of a specification and the meaning of the 
components are explained briefly below, with occasional reference to the stack example. 

The name of the abstraction, which is the same as the name of the principal type, is 
introduced by the keyword type. An optional abbreviation for the name of the principal type 
is introduced by the keyword as. The name of the type is followed by an optional list of 
parameters, enclosed in square brackets. If there is a parameter list, then the specification is not 
a single definition, but rather a definition schema, which can be instantiated by substituting a 
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Figure 3. Stack 

type stack[E] 
requires 

with 



as S 
E : type 

empty: 

push: 

pop: 

top: 

null. 



E xS-*S 

S -> S + < stack.underflow : > 
S —*■ E ♦ < stack.underflow : > 
S —* boolean 



representation: sequence[E] 

restrictions: none 

identity: sequence[E]f equal 



operations: 



end stack 



empty() = sequence[E]fempty() 

push(e, s) = addlast(s, e) 

pop(s) = if «s = then (stack.underflow : > 

else s[ I .. (#s)-| ] 
top(s) = sequence[Ejllast(s) 
null(s) = if «s=0 then true else false 



t the empty stack 



t is $ empty? 



% • is length 

% s[ a .. b ] is subrange 



suitable expression for the occurrences of each parameter in the body of the definition. If there 
is a parameter list, there must also be a requires clause which specifies the restrictions on the 
expressions that may be substituted for each parameter. In the stack example, the parameter E 
is restricted to range over the names of types (E is the name of the type of the elements on the 
stack). 

The keyword with introduces a specification of the signature, in the notation 
introduced in Section 2.3.3. The signature gives the name and type of each externally available 
operation, including the number and types of arguments and the number and types of return 
values for each possible termination condition. The set of subordinate types is also implicitly 
specified, since it contains precisely those types, other than the principal type, that are used as a 
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component of lite domain or range of some operation in the signature. Each operation may 
also have an alternate syntactic form, which is introduced by the keyword as. Within the 
definition of an alternate syntactic form, the expression "arg n" stands for the n-th argument to 
the operation, and all of the other symbols (up to the end of the line) are separators (prefix, 
infix, postfix, etc.). which are to be taken hterafly. Tbetypeof an operatioflt (i e . the name of its 
defining abstraction) should be obvious from its context. In cases where it is not obvious, or 
where we want to emphasize the type, we wiH use the standard functional notation, where the 
name of the operation is prefixed by the name of its defining abstraction followed, by a ,"£- 
The parameters of the type wifl be included in cases where that is helpful to the (human) 
reader.* ■ 

The interpretation of the principal type is specified by the next three components. 
The underlying representation algebra h specified by an expression introduced by the keyword 
representation The allowable expressions and their meanings are discussed below in Section 
4.3 below. The restrictions component specifies a subset of the principal type erf the 
representation algebra, and the Identity section specifies an equivalence relation on that subset 
The interpretation of the principal type is the quotient of the specified subset of the principal 
type of the representation algebra with respect to the specified equivalence relation. The 
identity relation in effect determines the identity of the abstract objects, of the principal type of 
the abstraction being defined, and serves as the logical equality relation for the principal type of 
the model. Logical equality is not externally available unless one of the opersrtions of the 
abstraction happens to coincide with it. In a reduced model, logical equality should be 
externatty obscrvabk* in terms of the operations, although not necessarily in terms of the same 
finite computation for all objects in its domain. 
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The operations are defined in a section introduced by the keyword operations. The 
forms and meanings of the operation definitions are described in Section 4.2 below. 

Comments can appear at any point in a specification. They are introduced by the 
symbol "%" and extend to the end of the line. 

Auxiliary functions or abbreviations may be used in the definition of the operations. 
The types of any auxiliary functions must be given in the Internal section, and the definitions 
of any auxiliary functions or abbreviations must be given in the definition section, in the same 
form as the types and definitions of the operations. Auxiliary functions are introduced solely 
for clarity and expressive power, and they are not externally available (for use by programs) or 
even part of the model, which contains only the functions acting as the interpretations for the 
externally available operations. Auxiliary functions may be used in assertions and in proofs of 
properties of the data abstraction. 

A specification is terminated by the keyword end, optionally followed by the name of 
the abstraction that was defined. In cases where several data abstractions are subordinate to 
each other it is necessary to define a group of related abstractions by a single model with 
several principal types. In the specification language, a module defining a model with several 
principal types consists of the keyword module, followed by any number of type definitions, 
followed by end module. The representation and the internal functions of each type are 
accessible throughout the module. Modules may not be nested. 
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4.2 Defining Operations 

The principal type of a model is the quotient of the subset of the principal type of the 
representation algebra satisfying the constraints specified in the restriction* section with 
respect to the equivalence relation specified Hi the identity section. If there is no restriction* 
section, the entire principal type is used. If there is no Identity section, then the logical equality 
of the principal type of the representation algebra is used, and the quotient structure is trivial, 
since all of the equivalence classes are singletons m this case. 

The definitions of the operations in a type definition in our specification language 
explicitly define functions that operate on the elements of the principal type of the 
representation algebra. These functions are implicitly extended to operate on the equivalence 
classes that make up the principal type of the quotient structure in the usual way, described in 
more detail in Section 4.4.4. 

The following subsections describe the means for defining functions provided in the 
specification language, and then examine the constraints a function definition has to satisfy in 
order for it to denote a wen formed operation for the exception algebra or state machine being 
defined. 

4.2.1 Conditional Bbcpressions 

We will use a language for defining functions similar to that introduced by McCarthy 
in 1331 extended by the iota expressions described in the next subsection. 

A function definition consists of a function name, a list of variables, an equals sign, 
and an expression. Valid expressions are variables, iota expressions, functions applied to 
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expressions. and conditionals applied to expressions. Conditionals are written with the usual 
if-then-else syntax, and they have the usual meaning: 



# =•*• $n* b then sr else y) - x) 
-• b => {(if b then x else y) = y). 



The variables that may appear consist of the variables appearing in the list of formal 
arguments on the left side of the equals sign, and any local variables defined immediately after 
the function definition. A local variable is defined by writing its name, an equals sign, and an 
expression. Circular definitions sre*not allowed: it must be possible to eliminate an" of the local 
Variables from the right hand siderbf a function definition fey a finite number of substitutions, 
each of which replaces an occurrence of a local variable by the expression defining it. Local 
variables are a notations! convenience, in the sense that any definition using local variables has 
an equivalent definition without tocaf variables. " fFhe abbreviation* introduced by local 
variables cati be a very important aW in making th* structure of a functiort definition Wore 
apparent to the human reader, and they can at tinm dramatically shorten the text of a function 
definition. '■'•'■'■ r Y !l! ' * : ^ ' 

The functions that may appear on the left hand side of an operation definition are the 
primitive operations of the representation algebra and of its subordinate abstractions, and the 
operations and auxiliary functions defined in th# type specification Of Metier to which the 
defining expression appears. Recursive definitions are allowed Auxiliary functions must be 
defined in the definition section. Auxiliary functions can increase the expressive power of the 
language, as proved for equational axiomatic definitions in K$ ■'■ Tills result should" not be 
surprising, since auxiliary functions may be defined recursively, so that the process of 
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substituting the body of the function definitions for each invocation (attempting to eliminate the 
auxiliary functions from the main definition) may fail to terminate. 

Since the operations of a data abstraction are supposed to be totaJ functions, it if 
necessary to show that all recursive definitions used are weH founded. 

4.2.2 Iota Expressions 

Iota expressions are named for the iota operator in tope. An iota expression has the 
form x ; #4 where x is the only free variable in thepregjeate £(*}, If* « of type T. and If the 
set { x c T I #x) J is a singleton set, then the value of the iota expression x ifM Is the unique 
element of that set. and otherwise the iota expression is undeiined. 

Iota expressions are useful in cases where it U much easier to specify a property the 
result of a function must satisfy and to prove that the property uniquely determines the result 
than it is to provide a recursive definition of the function. Iota expressions are the equivalent 
of Hoare style input/output predicates for a language with functions and without side effects. 
An examples of a definition where an iota expression definition is appropriate is 

isqrtOO - J : J 2 * n < (y*!) 2 

which defines the integer square root function. 

It is necessary to show that each iota expression used in a specification is well defined, 
given the context in which it appears. M«e pmUely, the fottowing two requirements must be 
satisfied for each iota expression x : /&): 
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1. q(x) => 3x t ftx) ] ,. v 

2. Vx,? [ ?<x) & #x) 8c q(y) Sc fa) => x s y J 

where e is the equivalence relation defined in the Identity section, or the logical equality 
relation if there is no identity section, x ranges over the principal type, and where q(x) is the 
path predicate describing the conditions under which the iota expression can get evaluated. Let 
a be an occurrence of an iota expression in the expression e, and let path(a, *) denote the path 
predicate for a in e. Then path(«. e) is defined as follows: 

path(a, a) - true 

if e is 7t*|. . *„)" and a occurs in x t then path(a, e) - path{a, x t ) 

if e is'ifb then x else f and & occur* in b then path(a, #) * path(a, W 

if e is "if 6 then x else y" and a occurs in x then path(a, e)-bte path(a, x) 

if * is "if i then x else ji" and a occurs, vn% then patbfo^ - ^ Mt patWet, y) 

4.3 Constructing Algebras 

Our approach will be to define a standard model for a d« ^ abstraction In terms gf a 
given representation algebra. The principal type of the standard raodel will in general be the 
quotient of a specified subset of the principaUype of the representation algebra with respect to 
a specified equivalence relation. The ^operations of tUe standard rood«l will be defined in terms 
of the operations of the representation algebra,.as described in the previous section* The r?st of 
thjs section is devpted to defining a « ich set tf representation a4gebrat (bateau be used as 
building blocks for defining models. ;.,.-.-. ,..,,..,,.-.... 

Since it is not our aim in the present work to investigate the foundations of 
mathematics, we will assume that logic, truth values, sets, cartesian products, natural number* 
and integers are primitive. An excellent formalization of these structures can be found m [48]. 
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We will use the notations summarized below. 

T and F denote the truth values true and false respectively. These are the only truth 
values, and they are distinct, k, v,-% =>, and s denote the and, or, mf, implies, »mi equivalence 
operations on the truth values, respectively, and V and 3 denote the universal and existential 
quantifiers. < , U, fl, and -denote set membership, union, intersection, and ^difference. Finite 

sets are written { X| x„ } and finite cartesian products or n-tuples are written < *| . ... , x n >. 

The /-th component of an ntuple X is written XI*, so that <X| , ._ ,x„ > - x { . The set of 
natural numbers is denoted by H. 0, o\ ♦, ♦, <, and - denote zero, successor, plus, times, less 
than, and logical equality on N, respectively. The set of integers is denoted by Z. and ♦, «, -, 
quotient, remainder, ate, ^and - denote plus, times, (unaty) mmus or (binary) subtraction, the 
quotient and the remainder of integer division, the absolute value operation, rhe tess than 
relation, and the equals relation, respectively. We rely on (he context to differentiate, between 
operations on the integers and operations on the natural numbers with the same name. The 
usual d/cimsl notation wHHJe used for Integer comtamU, which are considered to be an infinite 
class of nonary operations from the fbrrna1poi«fof¥kw. ! 

We wHT define a number of ways for defining algebras, namefy finite enumerations, 
finite cartesran products, finite disjoint unions, finite power sets, ftnite sequences, and recursive 
definitions (ffxpoint equations). The set of representation a%ebras is defined to be the set 
generated by the standard model for the boolean algebra defined below with respect to the 
constructions Hsted above (i.e., the smallest set of algebras that i* 'tirjserj" with' rtspect to the 
constructions for generating new algebras). Each of the constructions supplies a set of 
operations as well as a set of data objects, so that we are generating a set of algebras rather 
than merely a set of sets. 
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We also define two special purpose algebras, token and «tate[D], for use in defining 
the phylum of system states in a state machine model. Tokens and states have interdependent 
meanings, and are defined by a single module with two principal types. These two abstractions 
codify the ways in which the operations of a state machine can depend oft the system state. 

4.3.1 Booleans 

We want to have an image of the domain of truth values as one of our representation 
algebras. Since everything else depends on the boolean domain (predicate operations return 
values of type boolean), we cannot use the methods described below" to define it without 
introducing a circularity. We will define booleans in terms of the truth values In the 
underlying mathematics. A necessarily informal definition Hi a notation similar to our 
specification language is shown in Figure 4. Because the meaning of a data abstraction is 
defined in terms of booleans (cf. behavioral equivalence, Chapter 3>, we insist that the booleans 
begtven their standard Interpretation ifrall models under disdissiort 

Note that the tfuat operation on the booleans ii the same as logical equivalence oh the 
underlying domain of truth values, which in turn is the same as the logical equality on the 
boolean domain. In keeping with our policy that the only externally Observable properties of a 
data abstraction are those that can be calculated in terms of the operations, we will always 
interpret "»" as the wpttl operation of the^efinmg abstractibn of ihetype of the ctata objects 
bewrg compared. Thus if is proper to use "»" in the definition of an operation bhty If the 
representation, type has an equat operation. Gare must be tike! that miqual operation of «H 
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Figure 4. Boolean Abstraction 
type boolean ms B 



with 


true: -* B 




false: -» B 




not: B — > B 




and: B x B -* B 




or: B x B -+ B 




implies: B x B —> B 




equal: BxB-»B 


representation 


B » truth values 


operations 


true() - T 



as - arg I 
as arg I fc arg 2 
as arg iv arg 2 
as arg I =» arg 2 
as arg I - arg 2 



end boolean 



falseO - F . . - 
not(x) - if x then F else T 
and(x, yi - If jc jtheo y.ejse. F 
or(x, y) « if x then T else y 
implies(x. y) - (-»x) y y 
equaKx. y) - (x => y) & (y => x) 



the algebras defined is in fact an identify relation/ Logical equality is assumed to be defined 
for the structures that have been imported from the underlying mathematics, such as the 
natural numbers. 

The boolean type is isomorphic to the domain of truth values in the underlying logic, 
as indicated by the interpretations of the operations true and/a/* in the standard model tor 
the booleans. The operations of the representation algebra correspond to those of the 
prepositional calculus in the underlying logic. QuantifieA are defined only in the underlying 
logic, and have no counterpart in. the representation algebra- We will make heavy and implicit 



I. An identity relation equal must be reflexive, symmetric, transitive, and must satisfy the 
substitution property equal{x, y) => P(x) = P(y), for any predicate P. 
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use of the isomorphism between the boolean s and the underlying domain Of truth values, so 
that the primitive predicates of any representation algebra* which return values of type boolean, 
can be combined with quantifiers, and used in if-tftetr-'else expressions, both of which are 
defined in terms of the underlying logic. The booleans are the only type for which we will talk 
about properties of the interpretations of the objects directly. For all other types, we will talk 
only about the results of applying the primitive operations. The only direct connection to the 
underlying mathematics is by means of the booleans, which is why that type is given a 
distinguished status. 

4.3.2 Natural Numbers and Integers 

We import the systems of integers and natural numbers directly from the underlying 
mathematics. Definitions of these types are given in Appendix II. These definitions serve to 
pin down the syntax, and have nothing surprising in them. ,-.,-,,?, ~ V 

4.3.3 Enumerations 

Enumerations are useful for defining small finite sets, such as characters. Larger finite 
sets, such as fixed length integers, are most conveniently described in terms of the infinite sets 

•■^ :'■' i '■■■'■'.■■■■■ ' . s "'. ■ ' 

they are intended to approximate, as will be illustrated later in this chapter. 

An enumeration { X| , ... , x n } defines an algebra whose principal type is a set with n 
elements, and whose only subordinate type is boolean. The algebra has n nutlary operations, the 
constants x t for I < i < n, and one binary operation, equal, which allows the elements of the 
principal type to be distinguished from each other. We want equaK*,-, */) to be trUe if and only 
if i = j. The indices range over the set of natural numbers H. There are many models that 



-78 



Figure 5. Enumeration Types 
iypej x,.. , x„ } esT 

*»ftn x t : -*T fcrl<l<t 

equal: TxT - * boolean 

representation: natural numbers 
restrictions: < such thatl < i < n 
Identity 

operations: x^) - i for I £ i S n 

equate, b) « if a « b then true ehe false 
end 



exhibit the behavior described above: "Our s^rtdaitf model shown* in figure i"5,'" uses natural 
numbers to represent the elements of the enumeration. The V operation used in defining the 
equal operation of the enumeration type denotes the equality operation of the natural numbers. 

4.3.4 Tuples 

Tuples are labeled finite cartesian products. We will write tupleln>| : 5j , ... , w n : S n l 
for the set of n-tuples such that the i-th component is a member of the set 5j and bears the 
label w i% for each i in the range I < i < n. We win write < Wj : xj, .., , w R :x n ) for the tuple 

containing the elements xj x n . The projection, function mapping a tuple to its i-th 

component is denote by pta/,1 and if t is a tuple, then pfojX*) can Jw abbreviated as f. w,-. If 
f - < i»l : xj , ... , «/„ . x n >, then t.w^x i for each I in the range I < ( < n. , Two tupjes jire 
equal if and only if corresponding components are equal.. Equality of tuples is defined for the 
type tupie[n/| : 5j , ... , n> n : S R } if and only if the defining ajgebra of Sj has an equal operation 
for each i in the range \ < i < n which is an identity relation. If some of the component types 



-79- 



Figure 6. 


Tuple 












type 




tliple[«/| : 


:5,. 


• w n ■■ S J 


asT 




requires 




s t ■■ «w* 






for 1 < i < n 




with 




construct: 




S, x ... x S n -* T 


as < b/| : Xj , .. 


• • w n : ** > 






fAw f }. 




T -» 5 f 


asargl. «y 


fori <l < n 






equal: 




T x T — > boolean 







representation T = 5j x ... x S n 
restrictions none 

identity equal 

operations construct^, .... x„) - < x { , ... , x n > 

p[w t Kx) « x I i 

equaKx, f) = if Vi { I £ i< n ■* x* » { - ?. w i J thm true else false 
end tuple 



do not have equality operations, then the tuple type does not have an equal operation either, 
although the type and all of the other operations on it are well defined. 2 

This description is summarized in Figure 6 in an informal notation. Recall that 
cartesian products are primitive, and that if x is an n-Uiple, then x li denotes the frtfi 
component of the n-tuple. 



2. An equal operation will be defined for every representation algebra in our basic set. It is 
also possible to construct tuples with components from user defined types, which need not have 
an equal operation (e.g. stacks). 
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4.3.5 Oneofs 

Oneofs are finite labeled disjoint unions. A oneof is the dual of a tuple, in the sense 
that the projection functions go in the other directioo. * We will write owa « f [a>| : 5j, ... , w„ : 5 n ] 
for the disjoint union of the sets Sj , ... , 5 R . Our standard model for 
oneof[w t : Sj, ... , w n : 5„1 shown in Figure 7, uses the set U [h^xS^ to represent the 
principal type, which coincides with the standard interpretation for disjoint unions used in 
classical mathematics. Each element of a disjoint union if represented as a pair containing an 
element of one of the component types, and a label frtdicatihgwhieft 'component the element 
came from. If an element occurs in more than one of the Sp it will occur in several distinct 
elements of the disjoint union, distinguished by different values for the label component of the 
pair. 

RQtfffC 7v OiiOO* - 

type oneofCw, : 5j. . , r» n : 5 n ) *s O 

requires S t : type for I < / S « 

with inty} 5 a -> O a* erg I in w t for I < i < n 

toluijl O — * 5j ♦ < wrongjype : ) ma aro. I to » t for I < i < n 

isfw^J: S t — » boolean as erg I is tt ( for I < i £ n 

equal: O x O — *■ boolean 

representation O - U { w, } x 5, 

\<i<n ' ' 

restrictions none 

identity 

operations intw^Xx) - < w,-. x ) 

tofa^Xo) - if o 4 I > »| then o i 2 else < wrongjype : > 

is[w,Xo) « if o 1 1 = w t then true eke false 

equaKol, o2) - if ( ol 1 1 - o2 i I 8c ol i 2 - o2 1 2>then true else false 
end oneof 
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A oneof type has n injections from the component types into the disjoint union, n 
predicates indicating whether or not an element of the disjoint union came from a given 
component, and ti projections, which return (tie element without the label if the label 
corresponds to the component of the projection, and ¥?hich terminate in the wong-type 
exception with no return value otherwise. The Cfneof type has an equal operation if and only if 
each component type has an equal operation. 

As we shall see below, one of the main uses for disjoint unions is in constructing 
recursively defined types, such as trees. 

4.3.6 Sets 

We will write setlE] for the do^uffof finite subsets of the type E An informal 
definition of set[E] is shown in Figure 8. This construction Is valid only if the defining 
abstraction of the type E has an equal operation that compute? all identity relation, because 
equality is necessary for deciding set membership. Th,er^ is one miliary operation which returns 
the empty set of the given type, and there are operatio/is for adtTing and removing elements, 
and for forming unions, intersections, set differences; and restrictions, there are also operations 
for testing to se£ if an element belongs td a pi*$ seyf <^\seVi*a$ub^ of another, If two sets 
have the same members, and for finding the size of a set, which is always defined because we 
are dealing only with finite sets. Set restriction is^feafted as arj indefinitely large parameterized 
family of operations, where the parameters are jftrtf bound variable and the body of a lambda 
expression defining a predicate {i.e., a function from E to boolean). The size of a set is defined 
to be an integer rather than a natural number, so that stzes can be subtracted and divided. 
The natural numbers and the integers are defined in Appendix H. 
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Figure 8. Set 



type set[E} as S 

requires E : type with Eiequak E x E -* booJran such that idcnt_op(i4equal) 



with 


null: 


-»s 




add: 


ExS->S 




remove . 


ExS->S 




union: 


SxS-*S 




intersection: 


SxS-*S 




difference 


SxS->S 




restrictlx. p(x)l S -» S 




empty: 


S * boolean 




member: 


E x S -*■ boolean 




subset: 


S x S — *■ boolean 




equal: 


S xS -* boolean 




size. 


S-*int 


representation 


S - mathematical sets 


restrictions 


s such that ' 


. £ E and cardinals) c 


Identify ^ 


equal 




operations 


nulK) - { ! 





as arg I U arg 2 
a»arglflarg2 
as arg i - arg 2 

a»{ x: arg l| p<x)} 

afargi^arga, 
as arg I £ arg 2 
ms arg I - arg 2 
as | argl< 



definition 



end set 



add(e,s)-sU{el 
remove(e, sf - s - [ e ) 
unwrKsl, *2> - si U $2,, 
mtersectlorKsl, s2) - si fl s2 

difference^*!. s2) - si - s? 

restrktfx, p(x)Xs) =■ |x < s|p(x)} 

emptjKs) - «f 3 x [ x ( s ] thj$ fajse ebe true 

member<e, s>- ife i s then true else false 

subsetUl, s2) - if 3 x { x < ji,^ - ( * c s2 ),] then^aise else tt ue 

equatisi. s2) » if ( si £ s2 & $2 £ si > theft true ebe false 

size(s) - cardinality^) . , 

idenCop(0-Vxlftx.x}lK 

Vx,y[f(x,y)=>f<y,x)J* 

Vx.y* [ ffo y) * fty« *> ■*. K«. *> 1* 

VpVx > y[lXx f y)=*(P(x)sP<y))] 



In Figure 8, a definition of finite subsets of a type E is given in terms of ordinary set 



-83- 

theory. The notation in the figure is ambiguous, because we wish to use the standard notations 
for the usual set operations as abbreviations for the operations of the representation algebra as 
well as for the set operations of the underlying mathematics. The ambiguity is resotved as 
follows: within the definitions of the operations, the standard set notations refer to the 
operations of the underlying mathematics, while the as dauses in the signature section redefine 
those notations as abbreviations for the operations of jfhe representation algebra, for external 
use (i.e., when using representation algebras from the Mt fiumily to define standard models for 
other data abstractions). 

4.3.7 Sequences 

We will write sequenced] for the domain of finite sequences ctf elements of type E. 
An informal definition of sequences in terms of cartesian products is shown in Figure 9. 
Another definition, using a fixpoint construction, will be sketched M;tne jext section. 

Sequences have an exceptional termination condition tounrfi, which is associated with 

• -■->*"■ 

attempts to use elements of the sequence that do not exist. Sequences can be decomposed into 
the first element and the sequence containing aft Sut the first element, and also into the last 
element and the sequence of all but the last element, so that neither end of the sequence is 
preferred with respect to ease of access.- SubtartgeJ afe specified by giving the first and last 
elements of the subrange in the original sequence. Trie ; length of a subrange s[a..b] is 
1 ♦ b - a. Subranges with strictly negative lengths are hot defined, and an attempt to construct 
one will result in a bounds exception, with no return value. 
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Figure 9. Sequence 



type sequenceCE) 
requires E ; type 



with 



representation 

restrictions 

Identity 

operations 



emptyseq: 

addfitst: 

addbst 

botftrstr 

outlast: 

appcncb 

subrange 

prefix 

suffix: 

element: 

first. 

last: 

length: 

empty: 

equal: 

O- I* 

^ *>0 



as<£ 
<txE-> 

Q,x int x int 






Q, x int -* <£♦ (bounds 
Q, x int -> Q,* < bounds 
Q.x int — > E ♦ < bounds 
Q,-* E ♦ < bounds : > 
Q-* E ♦ < bounds . > 
Q.-*int 
Q,—* boolean 
Q.XQ,-* boolean 
(M>cE* 



'as'arg-2 ♦largt 
as arg 1 1* arg 2 



as erg If arg 2 
Q,« < bounds : > as arg 1 [ arg 2 .. arg 3 ] 
•sargH srd2) 
as argl [arg 2.. ] 
asargfl arg 2} • 



a* • erg I 

as arg I - arg 2 
*Ms the length 



end sequence 



.none .,......, ..,?. 

sequenceiequal 

emptyseqQ - < > 

addfirsKq, e) - < MtqX e , qTJl ... , q[«q) > 

addlasKq, e) . < WpqX qWL^ , qUql « > . 

butfirst(q) - q[2 .. «q} 

bu(bisKq) - qU . (•qMJ 

append(q, r) ■ if «q - then r 

eb* if «r - Qthen q 

else < H^rK qtll .. . q[«ql rfll .. . K«r] > 
subrangMq, i, j) - if (i •?, J>Af (| » <*& y (j <M) then ( bounds ; > 
else if j-i-l then <0) 

ete r <|£Lj#L-.fJP> 
prefix<q, i) - qTJ .. i) 
suffix(q, i) - aft .. «qj 
elementtq, i) - if (i < I) v (i > *q) then < bounds : > 

eheqi(M) 
first(q) = qfl] 
test(q). - ql«ql 
length^) « q i I 

empty(q) = If »q » then true else false 
equaKq, r) - if «q - «r «r Vi [ I < i < «q *■> q[i] - rfi] ] then true else false 
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4.3.8 Fixpoints 

It is convenient at times to introduce algebras whose principal t$»es have a "recursive" 
structure, such as the algebra of binary trees. While it is possible to define isomorphic images 
of such algebras using just the machinery introduced so far, by introducing appropriate 
encodings into the natural numbers, such a strategy does not contribute to the clarity of the 
resulting specifications. Instead, we will introduce explicit recursive (circular) domain 
definitions, which are considered as fixpoint equations over the domain of all algebraic 
structures. 

The representation component of a specification will always be a domain equation. 
In cases where the name of the algebra being defined does not appear on both sides of the 
equation, there is always a unique solution, since we are essentially solving for the fixpoint of a 
constant transformation. In cases where the representation algebra is defined in terms of itself, 
there may be many different solutions to the equation. Following Scott[46l we will introduce an 
ordering, and say that a fixpoint equation denotes the minimal solution with respect to that 
ordering. We will use the pointwise containment ordering on algebras, denoted by E. and 
defined below. 



Definition 19 Pointwise Containment 

Let a and b be algebras. Then a E b if and only if all of the following conditions 
hold: 

a. typenames £ b. typenames, 

Vot c a. typenames [ a. phyla a Q. b. phyla a ], 

«.opnames £ ftvopnarnes, ' 

V/3 c a. opnames [ a. operations/} Q, b. operations/} \ 

a. tcnames £, b. tcnames, 
a. arglength Q. b. arglength, 
a.argtypec;6.argtype, 
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a.tc Q.b. tc. 

a. rtength £, b. rfcngth, and 
a. rtvpe£fr.rt*p«. 
«»pt£*. pt 

If a E b, we wilt say that a is contained in 6. This means that for every phylum of a, b has a 

phylum of the same name, and for every operation of a, b has an operation with the same name 

and type. Every phylum of a is a subset of the corresponding phylum of b, and every operation 

of a is a restriction of the corresponding operation of b. The larger algebra b may have types 

and operations not present in a. The set of principal types for a must be a subset of the set of 

principal types of b. 

Note that E is reflexive, transitive, and antisymmetric, and hence is a partial ordering 
relation. Because E is antisymmetric if a minimal solution to a fixpomt equation exists, it must 
be unique. If we restrict ourselves to expressions built from continuous (with respect to E) 
transformations on algebras, then the existence of a solution is guaranteed by Kleene's first 
recursion theorem [231 which also gives us an explicit formula for the solution. 

Kleene's first recursion theorem states that if the transformation F is continuous with 
respect to E. then F(YF) - YF, and YF E A whenever F(A) - A. where YF ■= U F l ( I), U 
denotes the least upper bound with respect to E, F°(A) - A, F**Ha) - F{F(A)), and where 1 
denotes the least element with respect to E. In otheriwotdvtfi* exists,^ is th* least ffxpoint 
of the transformation F. In order to show that YF exists, it is sufficient to show that there is an 
algebra 1 such that i E A for every algebra A, and that every chwnvwftb respect to E has a 
least upper bound in the the domain of all exception algebras. It is easy to see that 1 exists: it 
is the algebra with all components equal to the empty set, containing no phyla and no 
operations. 
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Theorem 5 : Every chain with respect to Q has a least upper bound. 

Proof : Take pointwjse unions, details in Appendix III. 
End of Proof 

In order to use this result, we need a means of defining continuous transformations. 

This is also easy, because all of the methods for constructing algebras introduced earlier In this 

chapter are in fact continuous. The reasoning required to establish continuity is illustrated for 

the tuple transformation. 

Theorem 6 : The tuple transformation is continuous with respect to E. 

Proof : tuple preserves pointwise unions for chains of algebras. Details in Appendix III. 
End of Proof 

Since all constant transformations are continuous, and since the composition of two continuous 

transformations is continuous, it follows by an easy induction on the depth of the nesting that 

any expression composed from the constructors for enumerations, tuples, oneofs, sets and 

sequences defines a continuous transformation. Thus a minimal solution is guaranteed to exist 

for any domain equation expressible in our specification language. 

In order to make sure that the transformations defined earlier in this section are 
monotonic with respect to Q, we have to be a bit more precise about what the transformations 
are. (If a transformation is continuous with respect to E, then it must also be monotonic with 
respect to Q.) 

We will add an implicit parameter to each of the transformations, which specifies the 
name of the principal type of the algebra resulting from the transformation. The construction 
of the principal type and of the operations on the principal type has been described above. 
The subordinate types of each input algebra are included as subordinate types of the output 
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algebra if and only if they have a distinct name from that given by the implicit parameter. 
The names of the operations on the principal type are taken from the definitions of the 
transformations, and prefixed by the name of the principal type to make sure they are distinct 
from the names of the operations on the subordinate types. 

For any composition of tuple, oneof, set and sequence constructions, the implicit 
name parameters are to be chosen so that every occurrence of each constructor in the expression 
is given a distinct name parameter, and so that the name parameters are distinct from any of 
the names of any constant algebras occurring in the expression. With this proviso, any 
expression that can be formed from the tuple, oneof, set, and sequence transformations and 
any algebra constants will be monotomc with respect to G. It is also easy to see that the new 
phylum defined by a fixpoint construction wiH have the same name as its image under the 
defining transformation, so that the principal type 4s built up by successive approximations, as 
usual for a solution to a fixpomt equation. AIjo note that as defined above, each of our 
transformations maps complete models into complete models. 

An intuitive justification for choosing the minimal solution *o a domain equation is 
that we would like -our standard model to be reduced Ut-, free of unnecessary data objects). 
The explicit solution to the fixpoint equation can also be used to argue that the minimal 
solution is exactly the solution we would like to obtain, because it contains all of the objects that 
are finitely constructible using the operations of the representation algebra, and no others. To 
see this, note that any operation can produce a data object in a domain ^1) with an index I at 
most one larger than the index of some domain containing an argument of that operation (or 
one if there are no arguments). Therefore the results of some finite computation in terms of the 
primitive operations can produce elements of F l (D for finite natural numbers I, and alt of those 
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domalns are contained in the principal type of YF. Conversely, if our transformation F is such 
that every element of the principal type of F(A) is finitely constructible whenever all of the 
elements of the phyla of A are, then so are all of the elements of the phyla of YF, «r»ce the 
principal type of YF is just the union of the principal types of all of, the algebras in the chain 
F*(l). 

To illustrate the use of recursively defined representation a^ebras, consider the 
definition of immutable binary trees shown in Figure 10. Binaryjree is a family of data 
abstractions, parameterized by the type of the leaf nodes of thetree The leaf operation creates, 
a leaf containing a given element of type E, where a leaf is a kind ojt binary _tree. The trt< 
operation constructs a composite tree with given left and right subtrees. The /e/r and r/^A/ 
operations return the left and right subtrees of a composite tree, and terminate in the nasubtree 



Figure 10. 

type binary_tree(E] as T 

requires E : type 



with 



leaf: 


..- X^*T ■-■»:'■-■■'-- 


tree: 


T xT~*T 


right: 


T -> T ♦ < nojttbtfe* : ) 


left: 


T —> T ♦ < no_subtree : > 


value: 


T -> E ♦ ( notjeaf : > 


leaf?: 


T — > boolean 



representation T - oneof[ leaf : E, tuple[ left : T, right : T ] ] 

operations leaf(e) - e in leaf 

tree^y) - <teft: x. right : y > in tree 

right(x) - if isfJeafXx) then < no_subtree : > else tottreeXx). right 
leftM ^if i^leafX*> then (rralstrt^fee: felie toftreeX*). left 
value(x) = if isfJeafXx) then tofJeafXx) else < notjeaf : > 
leafi^x) w if isfJeafXx) then tfu^die fibi > ^r 

end binaryjree 



exception with no return values if applied to a leaf. The predicate leaf? tests a tree to 
determine whether or not ft is a leaf. The value operation extracts the element contained in a 
leaf node of the tree, and it results in a notjeaf exception if applied to a composite node. 

There is no qualitative difference between defining the operations of a model whose 
representation algebra is defined by a fixpoint construction and defining the operations of a 
model whose representation algebra is defined by some finite composition of tuples, oneofs, sets, 
and sequences. The domain equation specifies the structure of the representation algebra, and 
implicitly abo the operations available on the representation algebra, since each of the 
transformations mentioned above introduces some operations. For example, since the 
representation of a binaryjree is a bneof, the projections, injections, and domain test predicates 
of the given oneof type are available for use in defining the operations of binaryjree. This 
uniformity is a consequence of the fact that the representation algebra is an exact solution to the 
domain equation. 

The fixpoint construction can also be used to construct the natural numbers, and the 
parameterized family sequence[El A convenient representation algebra for defining the 
natural numbers is the solution to the equation 

nat - oneof [zero : { }, nonzero : nat]. 

This equation is based on the fact that each natural number is either zero, or it is the successor 
of some other natural number. Thus zero is represented as theeJement of the arbitrarily chosen 
singleton enumeration type { }, and any other, natural number ifjepresente&by its predecessor 
injected into the nonzero component of the disjoint union. Thiswwks because each injection 
adds a tag to keep the elements of a disjoint union distinct. Thus zero is represented by the 
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pair < zero, >, one is represented by the pair < nonzero, < zero. > >, two by the pair 
< nonzero, < nonzero, < zero, > > >, and so on, where the natural number n has n tags equal to 
nonzero and one tag equal to zero. A representation algebra suitable for defining sequence[E] 
is defined by the following equation. 

seq - oneof (empty :{ X }. nonempty: tuplefjirst : E, rest : seqH 

The reader is invited to fill in the details of the last two examples, to get some experience in 
working with recursively defined representation algebras. 

Another treatment of recursively defined domains can be found in [26, 25]. We prefer 
to avoid a category theoretic formulation, on the grounds that the subject can be treated 
satisfactorily in terms of a more widely known mathematical setting. 

4.3.9 System States 

In a state machine model, the current system state function is the disjoint union of the 
current individual state functions for each mutable type. When defining a state machine model 
in our specification language, we will explicitly construct only the individual state function for 
the principal type. The individual state functions for the subordinate types are taken from the 
standard models for the defining abstractions of the subordinate types, and the disjoint unions 
of the individual state functions required to get a system state function are left implicit. 

We provide two abstractions, tokens and states, for use in constructing the principal 
type and the individual state functions of a state machine model The interpretation of the 
principal type of a state machine will always be the principal type of the token abstraction, and 
the set of individual state functions for the principal type of the state machine will always be 
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stateCD], where [) is the set of data states for the state machine. 

The token and statefD] abstractions are defined by the standard model shown In 
Figure II. These abstractions have been defined so that the only property of a token that is 
externally observable is its identity, by means of the tokentequal operation. The only way to 
create a token or to extend the population of the principal type Is bf means of the state 
extension operation. 

The only way to extract any information from an individual state function is to apply 
it to a token to get the current data state of that token. If ail accesses to the state of a type are 
limited to the operations provided by the state abstraction, then we can be assured that the 
only state information in a state machine is that associated with the individual data objects, 
thus enforcing the assumption discussed in Section 3.2 and in Appendix I. 

New states can be created by the inlt, extend, or update epefatttxis. T#ie>ii|« operation 
creates an empty state. This operation has been included for completeness, since it is required 
to define the initial state of the state machine. The statetextend operation creates a new state 
in which the data states of all previously existing data objects are unaffected, and in which a 
new data object has been created, with a given value as its initial data state. This operation is 
used to describe the dynamic creation of a data object The statetupdate operation constructs 
a new state differing from the old one only at a single point in its domain, and it is used to 
model operations that change the properties of some existing data objects. 

tn addition, there is an internal function statetused, which tests whether a given 
token has ever been created in a given state. This function may not be used in defining the 
operations of a standard model, but it is useful in assertions and proofs about dynamic data 
abstractions (see Section 5.4). Note that the used operation will say that an object that has been 
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Figure 11. Tokens and States 



module 




type token 


as T 


witti 


equal: 



T x T -* boolean 



representation iitt 
restrictions x such that x > I 

identity 

operations 

end token 

type iStateCD] 
requires 

with 



equal 

equaKi, j) » if inttcquaKi, j) then true else false 



as S 

D : type 

init: — * S 

extend: SxD-*Sx token 

update: S x token x D -> S ♦ < undefined .object : > 

apply: Sxtoken^-*© s ai f •!« I ( arg 2 ) 



representation & - sequence!!)} 
restrictions none 



identity 
operations 



Internal 
definition 

end state 
end module 



saquencelequal 

init<) - < > 

extend<s, d) » < s j+ d, I « <«) > 

updates, t, d) - if I < t < ts then si .. (H)l !♦ d *| si <M) .. 3 

else < undefinedjobject : > 
applyfo t> - if 1 < t < «s then sM?e«e undefined 

used: token xS-» boolean 

used(t, s) = if I < t < « then true else false 



created and then destroyed (by changing its data state back to undefined using statetupdate) 
has been used, so that in general the used operation does not say whether a given object exists 
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in the current state. (For secure data abstractions, the two nations coincide.) 

The reason for defining tokens and states in the same module is to limit access to ft* 
operations on tokens. Note that the definitions of the state operations use the representation of 
tokens, which is available throughout the module, but not outside it. If tokens were defined in 
a separate module, then the representation would not be accessible, and additional operations e«V 
tokens would have to be provided so that the state operations could be defined However, we 
do not want modules other than the definition of the state abstraction to have accewto trtf 
operations on tokens other than equal. We freely admit that this is an ad hoc solution, and we 
refer the reader to [21] for a description of a general access control mechanism for data 
abstractions. r v 

An individual state function is restricted to take on the special value undefined 
except at a finite number of tokens. This restriction assures erthet the domain of system Ketes 
is countable, even though it is a function space on an infinite d omain . One consequence of tftii 
is that we have no need of Hmit constructions or transfinite inductions' in reasctting ebetit 
system states. 

A state machine modeMor the uniquejd abstraction is shown in figure 12. Since the 
specification has a data states component rather than a representation component, wefcnow 
that a state machine is being defined, rather than an exception algebra, and that the 
representation of the principal type is implicitly defined to be the token abstraction defined in 
Figure II. In this case the set of data states is a singleton enumeration type. At least one proper 
data state isneeded to distinguish the objects that have been Seated from those that have not 
been <and have the data- state undefined); Untau*.ids are immoteble (oace a unfcjuejd Jws 
been created, its properties are fixed forever), so that one proper data state is all that is needed. 
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Figure 1 2. Standard Model for Unique «-id 

type uniquejd ms U 

with create: —*■ U 

equal: UxU-» boolean 

data states D « \ null ] 

operations creatc(sX) = extend{s, nuB) 

equaKsXx, y) = < s, v > 
where v = if tokentequaKx, y) then true else fake 

end unique_id 



This example serves to illustrate the state change caused 3 oy^creaflon of a new data object in 
its purest form. The uniquejd abstraction is secure, since there are no operations that destroy 
unique_ids. 

A state machine model for a memory ceH containing a single object of type E Is shown 
in Figure 13 Celts are amorig the simplest mutable astaSbttra^li^.^t^Vr^ 
returns a new cell with a specified initial conteM Nife the* the^stataiexteiitf operation 
returns a pair of values, containing the new s^te'in¥ a Men representing the newly created 
object. The new state is the Hrsf return vaUieoT eterf op^ttbn 3 of'a state rnachin^ inodel. and 
the old state Is the first argument hi an impleme^tatfert, the state is passed around implicitly, 
while it is explicitly represented in a state ^ riwc^lne 5 ^^ fc T^*W leiletted hi the signature, 
which has no mention of the state, and describes ofilylhe type stricture visible externally. The 
update operation returns ho data objects; but it produces fa i new state in which die given cell has 
a new value for its contents. The contents operaiioh. returns Ihe current contents of a cell, and 
the equal operation tests to see if two cells are identical. Beth of these operations do not modify 
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Figure 13. 






type celKE] 


asC 




requires 


E:type 




with 


create 


E->C 




update: 


CxE- 




contents: 


C-+L 




equal: 


CxC- 


data states 


D-E 




operations 


create(sXe) • e 


xtend(s, e) 



where 
end celt 



boolean 



updatefcXc, e) * sfate[D]tupdate(s, c, e) 

contents(sXc) - < s, s(c) > 

equaKsXcl, c2) - <s,v > 

v - if tokenfequaKcK c2) then true else false 



the system state. If we view cells as the Lvalues of the variablesgf a programming language 
[cf. 50], then the .equal operation can be used to determine whether or not there is aliasing 
between two variables: an assignment to one variable (a cellfupdate opera t^pn) will affect the 
value of the other if and only if the variables have <f J*a( Lvalues. 

Note that there is no such thing as an uninitialized cell. If we wanted to define a 
different cell abstraction, in which ceils could be created without, be^, initialized, then we 
would have to introduce an additional data state to indicate that a cell was uninitialized, since a 
token with the data state undefined represents a cell that has not been created yet. Since we 
require the operations of a data abstraction to be deterministic, an attempt to find the contents 
of an uninitialized cell would either have to result in an exception condition, or in some 
constant default value. 
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4.4 Well Formed Specifications 

A specification is well formed* It denotes : -itm* exception algebra or state machine. 
This will be the caw 4f the retirements described m the 1 followmg subsections are met. In 
addition, a. ; reasonably defined data abstraction shouW saUsfy the Tolkwing two constraints 

[cf. 41,101 ..-■ .--iv.'-,- - - -.;■■•: ,fo" • ' •■■'■ * 

Every operation of the abstraction rf should either take at least one argument fronj the 
principal type of rf. or it should produce at least one return value (in the normal termination 
c.ofldMpn)/rom-thef»4iKi|irt^ than one). 

The purpose of this constraint is to rule out functions that have nothing to do with the 
behavior of the principal type. < " 

There should be atleast one operation that produces a Value belonging to th* 
principal type which docs not take any arguments from the principal type If this constraint is 
not met, then there is no way to compute any 'values of the principal type, and thus the 
interpretation of the principal type in a reduced model is the empty set. 

Note that both of the above constraints can br<tetfty checked gfferi pit the signature 
of the data abstraction. They tan be wwe4 as xonstratnt* a tn-ecttre must satisfy Bn order to 
qualify as a meaningful data abstraction. ■- ■■ w.; :-;.;-» i = 

4.4.1 Type Correctness 

All of the expressions in the specification must satisfy the type constraints contained In 
the signatures of the abstraction being defined, the signature of the representation algebra, and 
the signatures of the algebras subordinate to either. This means that every operation must be 
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stipplied with the correct number of arguments, and that the definition of each operation must 
terminate in only those termtrutton cooditiot» tfeciflpd In the sigmture, and produce the right 
number and types of return values for each. TJ*is is not a purely syntactic checfc; because it 
may require praying that the expression defining an operation terminates in a given 
termination condition (usually the normal condition^ 

4.4.2 Representation Consistency 

The representation, algebra defined by the roproaon^atton section must either be a 
member of the set of algebra* generated by {betrostrttctionsgrven earner hi this chapter, oi* It 
must have a previously defined standard model If the representation algebra is defined in 
terms of a parameterized definition, the conttraints specified m the refprtrea section of the 
parameterized definition must be met, 

4.4.3 Representation Invariant 

If a restriction on ihe principal type of the re pr e se ntation algebra is specified in the 
restrictions section, then the range of each operatlan«defined t mast satisfy the restriction This 
condition can be established by an inductive argument: assuming that each argument from the 
principal type satisfies the restriction, show that each return value of each operation satisfies the 
restriction. 
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4.4.4 Congruence 

If a nontrivial equivale nee relation is given in the Identity section, then it is necessary 
to show that each operation is consistent with the equivalence relation, in the sense that it maps 
equivalent arguments into equivalent outputs. This requirement is a necessary condition for the 
implicit extension of the operations from the representation algebra to the quotient structure to 
be well defined, as described below. 

The operations are explicitly defined as functions that operate on the elements of tt*e 
principal type of the representation algebra. The model denoted by a specification is in general 
a quotient structure, and the interpretations of the operations of the data abstraction in that 
model operate on equivalence classes of elements from the principal type! of Tthe representation 
algebra. The operations can be extended to operate on equivalence classes in the usual fashion. 
If the operation/ takes a single argument from the principal type and returns a single value in 
the principal type, then the corresponding operation or] equivalei»cetlasses/ s ' is defined by 

/=<[x]) = ^x)] c:r 

where [x] denotes the equivalence class containing the element x. For the relation defined by 
the above equation to be single ialuedT and hence a function on equivalence classes, the 
function /must satisfy the following requirement: -n.- ,■■■ 

Note that if = is the same as the logical equality relation on the principal type of the 
representation algebra, then this requirement is automatically satisfied. An equivalence relation 
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that satisfies the above constraint is known as a congruence relation with respect to/. A 
definition of /= and of the congruence requirement for a general operation of an exception 
algebra or a state machine is given below. 

Let / be an operation of the abstraction A, /:«jX..xa a -» U /? T where 
R r - rj x ... x r,^). and let rf be the principal type of A. Let a denote the relation defined by 
the identity section of the specification Define the eouivalence relation <f by 

and define the "equivalence class" ec by 

eotx) - if x c rf the fxL^ else x ■' L 

If fix , x R ) - < T. < y,, ... , ^ T ^ > >, then/ H is defined by 

/^(ectxj), .. , «&„» - <T, iec(j|), _ , ecfy^ > > 
and /must satisfy the requirement 

tc(^,, .... *„» - tctfty, .... yj) k v; : i<£«<T) i ^obXA-i. .,;.^Mo«ag% ~ .. J»» A^J 

4.4.5 Termination 

Every operation must be shown to terminate in one of the termination conditions 
specified in the signature for any set of arguments of the proper type, given that any arguments 
from the principal type satisfy the restriction given in the restrictions section of the 
specification. 
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5. Correctness of Implementation 



Every well formed implementation of a data abstraction defines an implementation 
model for the data abstraction. The construction of the Implementation model is discussed in 
Section 5.1 below. Our basic definition of correctness fc that the impterrlentation model must be 
behaviors lly equivalent to the standard model of Ihe abstraction to be Implemented. This 
definition corresponds to the fntuition that there should be ho observable difference between 
the behavior of the iniptementation and the behavior of the standard model, cast into the 
framework of deterministic sequential computations. * 

The classical way to prove the correctness of an implementation with respect to an 
abstract mo«tebs^eciflcat«W is to exhibit a hdrtomorphism. Th Section 5.2, we show that the 
classical approach^ it sound iP^ standard model* ai^ model are both 

exception; algebras, by showing that the existence of a hwnomorphism from tht implementation 
model to the standard model implies that the two models are behavtorally equivalent. It was 
shown in Section 33.1 that the classical approach Is also complete for the static case, in the 
following sense: if the standard mode* is reduced, then there e>f«ra homomorpriism from any 
behavioralty equivalent implementation model to the standard model. 

Section 5.3 discusses the case where the standard model is an exception algebra and 
the implementation model is a state machine. It is shown that a correspondence function 
analogous to a homomorphism can be used to demonstrate behavioral equivalence. 

Section 5.4 discusses the case where the 1 standard model and the implementation model 
are both state machines. In this case there is no useful analog to the homomorphism theorem 
of Section 5.2, and proofs of correctness rest directly on the,definition of behavioral equivalence. 
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The proof methodology is illustrated by examples. 

5.1 Implementation Models 

An implemerttailon of a data abstraction 4 supplies a representation for ttie principal 
type, and an algorithm fojr computing each of the operatum. It at relatively easy to construct a 
model of the abstraction from an impkmemation, if the represeatation^bstraotton and all of the 
subordinate abstractions have been defined by abstract model tpeoJfriatiomi 

The principal type of the implementation model ii the reachable subset of the 
principal type of the standard model far the repreiettfatie* abstraction. The reachable subset 
contains just the elements of the principal tyfe that ate eoaa?atable by some* finite (dosed) 
computation hi, terms of the operations of 4 and the abstraction*; au bo r dmat a ft> 4. The 
interpretation of an operation of the principal type is the function computed by the p ro ced ure 
implementing that operation. The prin^l t^rae and opcniions of each abstraction 
subordina to to d are taken from the standard model 4>f the e ubordUiata abstraction. 

. The imptanentatton modd U complete by conicrudiea. since it contains interpretations 
for all subordinate abstractions. The ; iinplea*ioatatiofr model nu^ The 

construction guarantees that every ob^ of the principal type of theimpiemematlon model Is 
reachable. There is no explicit equivalence class 4truc*ure h> the imphwn ewt atton modet, so that 
several distinct implementation, objects may represent -the same abstract object. The 
implementation model is redujqed«if and only if each abstract object an a unique n^e^entation 
in the implementation modeJ. 
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5.2 Static Specification, Static Implementation 

The classical method for demonstrating the correctness of an implementation with 
respect to a standard model specification is to establish a horoorflbrplHsm from the 
implementation model to the standard model > ln^<¥§5 ieetibW *e pfesent a theorem that 
demonstrates that the classical method is sound for cases where both the standard model and 
the implementation model are exception algebras. ' 

5.2.1 Homomorphism Theorem 

Since an exception algebra has a disjoim imtort structure not present in the 
heterogeneous algebras of ft],- 'we have to extetfd'fhe definition of a homomorphism stighrtjr. A 
homomorpbism between two exception algebf as 'mu^* preserve i^ 

that the termination conditions of corresponding operation invocations must be the same, and 
that corresponding rewfrri value* mu&be^ honfci^ cortespxjhtHrig 

arguments are fteinbiworphfc images. More ' precisely, if il and u f are two exception algebras 
with the same signature, then a homiirhorpWsnvA fraiH AW& is a family of functions 
ft a : A* ph yla a — * B± phyla a . where a < A. typenSmeS. wW ttlfeifollowing property 

Let P = A. phyla. F = ^.operations, c /f.opnames, n ■ /4.arglength(0), 
let -a t - A. argtype«3, \i) and * t ( P a for each i intfce range t'3'i <?*,"■"-■- 

let < T, < jj. ... , y m > > » F0(xj x n ), 

where T c A. tc{/3), m = A. rlength(T, /3), 

and where r ,» A* rtype(T, |S, p and j.- < P r for eachi^" to the range 1 1 y & at. 

y j j 

Let G « B. operations. 

ThenC^A (x,) A (* n » = < T, <A ty), ... . * r . (y m ) > >. 
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The "«" in the conclusion refers to the equality relation on abstract objects. For models defined 
using the specification language introduced in Chapter 4, this rebrtkm i$ given in the Identity 
section of the specification. 

How we can state the homemscp hism theorem. 

Theorem 7 : Let Ml and Ml be complete exception algebra models with a common signature. 
If there is a homomorphism from Ml to Ml wh^h tfriwonij Jm the KMiHit f mapping on: the 
subordinate types, then Ml and Ml are behavioraHy equivalent. 

Proof : By induction on the length of the computation. Details nvApj>endix4II, e 
End of Proof 

The existence of a homomorphism indicates that the interpretation of any closed 
computation C in Ml is a step by step wnwifctioa ef the interpretation of C in Af2. 
Corresponding results (dau objects) may have different representations in the two models, bat 
they must have the same properties. Since, the bemomorpW identitf 

mapping on the hooleans, the Jrou^^ tha# any prMiittve 

predicate wjH give the same truth value for corresponding data object in Ml and M2. 

Note that we are dealing wkh comokte reocWi, which contain 4be operations of every 
type subordinate to the principal type in addition to the operations of the principal type M 
homomorphism must preserve all of the operations of an exception algebra, including those 
associated with the subordinate types. It 1* sufficient to explicitly consider only the operations of 
the principal type when proving the correctness of a static implementation, because the 
component of the homomorphism for each of the subordinate types Is the identity function, 
which trivially preserves alt of the operations of the defining abstraction of each subordinate 
type. The requirement that the homomorphism must reduce to the 5 ' identity mapping on the 
subordinate types is no restriction in practice, because of the way in which the standard model 
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and the implementation model are constructed. In both cases the interpretations of the objects 
and operations of the subordinate types are taken from the standard models of the defining 
abstractions of the subordinate types. Consequently, the subordinate types have identical 
interpretations in both models, and the natural correspondence between the two is the identity 
mapping. 

6.3 Static Specification, Dynamic Implementation 

In the case where the implementation algebra is a state machine and the standard 
model is an exception algebra, a correspondence function can be used to establish the 
behavioral equivalence of the two models in a way entirely analogous to the homomorphisms 
used in the case where both models are exception algebras. In the rest of this section we present 
a theorem justifying the use of correspondence functions, and an example to illustrate the 
procedure for establishing the correctness of a dynamic implementation for a static data 
abstraction. 

The correspondence function that is used to demonstrate the behavioral equivalence of 
a dynamic model and a static model is not a homomorphism on algebras, even though it must 
have similar properties. Some of the differences between homomorphisms and correspondence 
functions are outlined below. 

Recall that a homomorphism is a family of mappings, one for each phylum. Each 
mapping is a function from a phylum of one algebra to the corresponding phylum of the other 
algebra. The abstract object represented by some implementation object must be completely 
determined by the identity of the implementation object, since the mapping takes no other 
arguments. This works well in the static case. In a state machine model, the properties of a 



- 106- 

data object wilt depend not only on the identity of the object, but also on the current system 
state. Consequently a correspondence function must differ from a homomorphism by taking the 
system state as an extra argument. 

Recall that the principal type of a state machine contains tokens representing all of the 
data objects that can ever be created. In each system state the population of objects that have 
been created so far is the subset of the principal type with a proper data -State, while the objects 
that have not been created yet are all mapped into the (improper) data state undefined by the 
system state function. In system states where a given token has the data state undefined, the 
token does not represent any abstract data object, and after an operation is performed that 
assigns a proper data state to the token, the token represents the newly created data object. To 
make the correspondence a total function we adopt the following convention. A correspondence 
function must map a token into the special object undefined for any system state for which the 
token lies outside the current population. 

The properties of the newly created object are determined at the time the object is 
created, and have no particular relation to the identity of the token representing the object. 
Different computations can lead to states in which a given token has different properties, and in 
such a case the cdrres|>ondence function must map the token into different abstract objects in 
the two states. 

The correspondence between the tokens of the implementation model and the abstract 
objects of the standard model is established by a series of approximations, corresponding to the 
steps in the computation that create new objects of the principal type. Initially, the population 
of the implementation model is empty, and the initial correspondence is empty (i.e., in the initial 
state the correspondence maps every token into the improper object undefined). As new 
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objects are created, the image of the token representing the newly created object changes, from 
undefined in the state just before the object was created, to the abstract object represented by 
the newly created implementation object in thetsftrte just after it was created. For abstractions 
that do not attow the explicit destruction Of data objects, the correspondence functions for the 
sequence of system states produced by a closed computation are a series of pure extensions. If 
(T| represents the state produced by : the Hh step 1 of some closed computation, c Is a 
correspondence function, and I </,#»en it must be the case that 

c(x, <rp * undefined =*• cixff t ) « dx, (r ). 

We will refer to this as the mondtimkiiy property W correspondence functions. Once an 
implementation object has been created, and it has. come to represent a proper abstract object, 
the monotonicity property says that the implemerttltidhobject must continue to represent the 
same abstract object in all subsequent states. This is just what we would expect; if we- create an 
implementation object and assign it to a variable, we wpuld like to assert that the variable w4lt 
continue to denote the same (immutablejabstract object as long as we do not assign a new value 
to the variable. Spontaneous changes in the abstract identity of the value are not acceptable. 

A correspondence function must reduce to the identity mapping on the subordinate 
types, just as for a homomprphism. Note that for the subordinate types the correspondence 
function is independent of the system state. The abstractions we are considering in this section 
have static standard models, so that all of the subordinate types must be static, and all of the 
objects of the subordinate types must therefore exist in all possible system states, in the 
implementation model as well as in the standard model 
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6.3.1 Correspondence Theorem 

In this subsection we define ciwcespondeiKe fumtieni 4>f«ci(el)r. and we present a 
theorem supporting their usefulness. Let 4 be * su* machine and let fl be an eKceptkm 
algebra such that the signature of fl is contained m the signature of A A cor r e sp o nde n c e 
function from A to fl Js a famM| of functions * xyf-pbyla, x ^.phyla^—^fl.phfla^, where 
a c fl. typenames and where j <■ >*.$& isjhe name of; the^fhylum e^s|BS«em«late» for the state 
machine A. A correspondence c must satisfy the following property. 

Let P «• >4. phyla. F • A* operations, € fl. opnames, a - /I. argfcngth(/3), 
let o ( - A. argtypeOS, (} : and 1.^ c J» tw*q&ltati#upgtlZiSn, 

let cr c P y 

let < T, < (T'. y,, . y m > > - Ftfp, x,, „. , x„), 

where T c ^. tc<0L?Vf ^.w ^.rleng?h|r f i5^ 

and where r, - ^. rtype(T, 0.J) and yy c P f for each j in the range I < / £ m. 

Let G « fl. operations. 

Then Gp(c a (<r. x,X ... , c fl (ff , x n » - < T, < e T ff, y,), ... , c, (<r\ ^ > >. 

x < /» a ft a c 4*statensme« fc x ■* popuboon<fJ) -► t$X, x>- cfrj*. *fc 
and x c P a & -• a < /f. statenames =» c(ff, x) - dff'.x). 

« 
The correspondence property says that the correspondence rriust preserve all of the operations of 

the target algebra; Note that the new state 0* produced by the operation of the state machine is 

used to determine the correspondence between the results of the operation In the state machine 

and in the exception algebra. A correspondence function must also satisfy the monotoniclty 

requirement, as stated m the last two clauses. 

A correspondence function is distinguished from a homomorphism since it takes the 

system state as an extra argument, and since it satisfies the monotonicity property specified by 
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the second clause of the conclusion. Since the range of the mapping is an exception algebra, 
there is no component of the correspondence function for the phylum of system states. 

The correspondence theorem assures us that two models are behaviorally equivalent 
whenever there is a correspondence function from one to tht other. 

Theorem 8 : Let M\ be a state machine modefc swd Jet Af2 be an^xception algebra mode*. If 
there is a correspondence function from M\ to Af2 which reduces to the identity ♦napping on 
the subordinate types, then Ml and M2 are behavtoratty equivatettip I i ' 

Proof : By induction on the length of the computation. Details in Appendix III. 
End of Proof h 

The proof is very similar to the proof of the homomorphism theorem, except that <he 

monotonicity property is required to transfer properties of a data object from the state in which 

it was created to the state in, whjch it is used at an argument tea subsequent operation. 

5.3.2 Simple Example 

A very simple example to illustrate * proof of the correctness of a dynamic 
implementation of a static data abstractions developed in this subsection. We wiH consider ait 
implementation of ^be intpw abstraction in terms of wraf«!of integers; /nf^afrj are immutable 
pairs of integers, such as mjght be used to .repMsent rational numbers oivgaussten integers. 
Operations for constructing pairs, and for ejttrattmg the left and right components are 
provided. The jntpair. abstraction is ve*y simiiarto tufMeUtght r int. fcft HntJ An exception 
algebra mod§l for the j^/^^r abstj^action » ^w%if»J^pwe r*v n 

A state machine modelfor arrays is shown in FtgureiS. Arrays are mutable, and have 
a variable size. It is not possible to create an a#ray cwWt uninitialized elements. The arrays 
def ijrif d here axe a simplified version of CLU arrays* wbiea have more operations 
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Figure 14. Pairs of Integers 




type intpair as P 




with create: 


int x int — > P 


left: 


P-*irrt 


right: 


P-*int 



representation P • tupteOeft: int, right: int] 
restrictions none 

Identity tupleiequal 

operations create(x, y) - < right : X, leftt y ) 

left(x)-x.left 

right(x) - x. right 
end intpair 



An implementation is shown in Figure », and the implementation model is shown in 
Figure 17. The derivation of the implementation model from the Implementation is 
straightforward. The operations of the implementation model are described in the same 
notation as the operations of the standard mode* to avoid mtrodocing a host programming 
language. We claim that it is uwful to defwe the implementation modelin thb Style in doing 
practical proofs as well, thus separating the issues mvorved in establishing the correspondence 
between two different representations for a data abstraction from the problem of proving that a 
procedure written in a particular programming language implements a particular function. 

To prove the correctness of mis implementation, we have to exhibit a mapping c and 
demonstrate that it is indeed a correspondence function. The behavioral equivalence of the 
standard model and the implementation model will then follow from the correspondence 
theorem. In order to distinguish the operations of the implementation model from the 
operations of the standard model m the proof, we will prefix the implementation operations 



Figure 15. Arrays 
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type arraytE] 


as 


A 




requires £ : type 






with 




create: 


int -> A 






addh: 


A x int —* A 






add I: 


A x int — > A 






remh: 


A — * * ( bounds : > 






reml: 


A — > + < bounds : > 






store: 


A x int x E ~ > ♦ < bounds : 






fetch: 


A x int — * E ♦ < bounds : ■> 






equal: 


A x A —> boolean 






low: 


A — > int 






high: 


A -> int 






length: 


A -> int 


data states 




D = tupletlc 


iw: int, e: sequence[E}] 


restrictions 




none 




identity 




tupletequal 




operations 




create(sXi) = 


state[D]textend(s, <low: i, e: 



as arg I [ arg 2 ] :« arg 3 
as arg 1 [ arg 2 ] 
as arg I - arg 2 



addh(sXa, x) = (state[Djtupdate(s, a, (low: s(a). low, e: s(a). e I* x>), a> 
addl(sXa, x) = (state[D]fupdate(s, a, <low: s(a). low - 1, e: x *| s(a). e». a> 
remh(sXa) = if «(s(a). e) = then < bounds : s > 

else <state[D]fupdate(s, a, (low: s(a). low, e: butlast(s(a). e)>, a> 
reml(sXa) = if #(s(a). e) - then < bounds : s > 

else <state[D]tupdate(s, a, (low: s(a). low ♦ I, e: butfirst(s(a). e)>. a> 
store(sXa, i, x) •= if s(a). low < i < s(a). low ♦ «(s(a). e) - 1 
then state[D]*upd3te(s, a, (low: s(a). low, e: s(a). e[.. M] |* x ♦! s(a). e[i*l ..]» 
else ( bounds : s > 
fetch(sXa, i) = if s(a). low < i < s(a). low ♦ »(s(a). e) - 1 

then ( s , s(a). e[l - low ♦ i] > 

else ( bounds : s > 
equal(sXal, a2) «= (s, tokenlequaKal, a2)> 
low(sXa) = (s, s(a). low) 
high(sXa) = (s, s(a). low + »(s(a). e) - 1) 
length(sXa) - (s, «(s(a). e)> 



end array 



with a "i". To help the reader distinguish elements of the standard model from elements of the 
implementation model, variables ranging over implementation objects will also be prefixed with 
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Figure 16. Implementation 

representation arrayOnt] 

operations create(x, y) - addh(addh(arraricreate<l>, xfc y) 

krft(p) = fetcMp. I) 
rlght(p) - fetch<p, 2) 



Figure 17. Implementation Model 
representation array tint] 

operations create(sXx, y) - addh<s2Xp2,y) 

where <s2, p2> - addMsiXpl, x) 

($1, pl> - arraytcreate($i) 



Wt(sXp) - fetcMsXp. I) 
right(sXp) - fetcMsXp. 2) 



aV. 

The correspondence function for ^sexsriipieU ttmlpttowtofv 

c($, a) - (left: s(a). eCHrtght. s(a). e[2;> 

We have shown only the component of the correspondence for the principal type impair. The 
correspondences for all other types are identity functions. 

The proofs for the operations cmtt and fefi, are $hown below. „ The proof for the 
operation right is similar to the proof for left, and is left as an exercise for the reader. Th* 
proof relies on the implementation invariant I shown below, which is a restriction on the data 
state of every object representing an *n//c«r. 
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Let x, y be integers, 

ia, Ip be lintpairs, 

is, IsO be system states for iintpairs, 

Let I = is(ip). low = 1 fc »(is(Jp). e) = 2 

create 

Let (is, ia> = lcreate(JsOXx, y). 

We have to show that cUs, la) = create(x, y). 

From the definition of create, create(x, y) = (left: x, right: y>. 

From the definition of c, c(ls, la) = <left: ls(la). e[I], right: is(ia). e[2]>. 

Using the definition of tupletequal, we have to show that 

is(ia). e[l] = x and 4s(la>. e[2] = y. 

From the definition of the array operations create and addh, 

is(ia) = <low: 1, e: <x, y» and ls(lp) = 4s0(lp) for ip * ia, 

so is(la). e[l] = x and is(la). e[2] = y. 

So c(is, ia) <= create(x, y). 

Since ia is newly created and is(lp) «= isCKip) for all ip * ia, 

the monotonicity property holds. 

Since the array operations create and addh can only terminate in the normal condition, 

c preserves the termination condition of the create operation. 

So c preserves the create operation. 

Also is(ia). low . I & «(Js(ia). e) = 2 and ls<4p) = isO(lp) for ip * ia, 
so that the implementation invariant holds in state is if it holds in isO. 

left 

Let <is. x> - ileftOsO, ia). 

Let a = c(is, la). 

We must show that x = left(a). 

By the definition of c, a = (left: ls(ia). e[l], right: is(ia). e[2]>. 

By the definition of left, left(a) = is(la). e[l]. 

From the invariant, isO(la). low = I & *(lsO(ia). e) - 2 

so 4s0(ia). low < I < isCKla). low + •<isO(la). e) - 1, 

and by the definition of ileft and arrayjfetch, is «= isO and 

x = isOUa). e[l - I ♦ 13 = isCKJa). ell]. 

So x = left(a). 

left and Heft always terminates in the normal condition. 

So the correspondence c preserves the left operation. 

Since is = isO the monotonicity requirement is trivially satisfied. 

The implementation invariant holds since is «= isO. 

right 

Proof left to the reader. 
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For the purposes of comparison, if immutable sequences had been used as the 
representation of intpair instead of arrays, the homomorphism would have been the following 
for the analogous representation: 

A(x> -< left: xDl right: x[2] >. 

The proof would have been similar for the immutable cue, except that there would have been 
no need to show the monotonicity property, and no need io argue that the data stales of 
previously existing data objects satisfy the implementation invariant, as we did for the tteaie 
operation. For a mutable implementation, it is important to include this part of the argument, 
because the implementation invariant is a constraint on <he entire system state, rather than Just 
on the images under the new system state of the data objects returned, A correctly implemented 
operation must preserve the invariant, which means that the invariant must hold with respect 
to all data objects after the operation is performed. This includes the objects returned by the 
operation, as well as any others whose state may have changed as a result of the operation. 

Note that the proof methodology presented here has no difficulties handling 
implementations with benevolent side effects. If the correspondence function is many to one, 
then an operation may change the state of an implementation object without affecting the 

:•$ . ■■;: -•'•■, : v -:- : 

correctness argument, as long as the image of the implementation object under the 
correspondence function does not change. Sucbside. .effects can be useful in cases where an 
operation rearranges a data structure to make future operations on that structure more efficient, 
without changing the externally observable behavior of the structure. 
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5.4 Dynamic Specification, Dynamic Implementation 

The correctness of a dynamic implementation of a dynamic data abstraction can be 
proved by constructing a simulation relation, and by showing that the simulation relation holds 
for all closed computations. The method of simulation relations is a general solution to the 
problem of proving the behavioral equivalence of two models, since it can be applied to both 
static and dynamic models. If the standard model is static, then some simplifications are 
possible, as illustrated by the homomorphism theorem and the correspondence theorem 
presented in the previous sections. In this section we consider the fully dynamic case, where the 
full power of simulation relations is needed. 

Recall that each object of a dynamic type is modeled by a token. Tokens have no 
distinguishing features other than their identities. The properties of a data object represented 
by a token are modeled by the images of the token under the current system state function. To 
establish the behavioral equivalence of two models, we must specify the correspondence between 
the tokens of the two models, and also the relations that must hold between the states of 
corresponding tokens. The first of the two correspondences is the correspondence relation «+ 
described below, and the second is described by the simulation relation. For a pair of state 
machine models, the simulation relation is typically defined in terms of the correspondence 
relation. 

Since tokens do not have any distinguishing properties other than their identities, it is 
generally not possible to describe the correspondence between the tokens of the implementation 
model and the tokens of the standard model without reference to the computation that produced 
the current state. The correspondence relation for tokens is easy to describe in terms of the 
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computation, since the results of corresponding steps of the computation in the two models must 
correspond to each other. The correspondence relation is defined mere pcMiseiy as follows. 

Definition 20 Correspondence Relation 

If the computation C is feasible in models Ml and M2, if x is thei-th return value of 
the j-ib step of the interpretation of C in Mi, and if j is the Hh return value of the 
J-th step of the interpretation of C it* Af % then we will say that x oorreaponds to y 
and weWrtl write x ** j. 

The correspondence relation applies to system states as weH as to data objects. The 

correspondence relation is syntactic in nature it is defined in terms of the structure of the 

computation, without any regard for the meanings of the operations, so that the same definition 

applies to all data abstractions. 

The simulation relation describes the relation that must hold between the states of 
corresponding data objects in the two models for the objects to have the same externally 
observable behavior. Examples of simulation relations can be found in the proofs of correctness 
given in the following sections. 

A typical proof of correctness proceeds by induction on the length of the computation, 
to show that for any closed computation, the termination condition of the last step is the same in 
both models, and that the simulation relation holds in the final states of the two models. The 
proof splits up into cases on the type of the last operation of the computation, with one case for 
each primitive operation. 

To establish behavioral equivalence, the simulation relation must imply that 
corresponding boolean values are equal. Typically the simulation relation will be the 
conjunction of a number of clauses, where each clause is an implication. The hypothesis of the 
implication says that a number of pairs of objects have given types and are related by the 
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correspondence relation «. The conclusion describes the relations that must hold between the 
identities and states of corresponding objects. The clause stating the standard requirement on 
boolean values is the following; 

b ~ lb => b = ib, 

where we follow the convention that variables prefixed by a "i" refer to elements of the 
implementation model, while variables without such a prefix refer to elements of the standard 
model. Just as we required the homomorphism or correspondence function used in a proof of 
correctness of a static data abstraction to be the identity mapping on the subordinate types, we 
will in general require a clause in the simulation relation for each subordinate type, stating that 
corresponding objects of the subordinate type must be equal. 

In order for the induction to go through, the simulation relation must be strong 
enough to enable the simulation relation to be proved in the final state, given that the 
simulation relation holds in all previous states. In working out sample proofs, we have found 
that the definition of the simulation relation usually evolves along with the proof. In the 
beginning, the simulation relation states just the required constraints on the boolean domain 
and on the other subordinate types. In considering each operation, it is often found that an 
additional hypothesis is required to show that the operation preserves the simulation relation 
defined so far. As clauses are added to the simulation relation, it is of course necessary to go 
back and show that the other operations preserve the new clause as well. If the implementation 
is in fact correct, then this process will eventually terminate in a proof that every operation 

« 

preserves every clause of the simulation relation. 

The use of the correspondence function « is one difference between proofs of 
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correctness far dynamic abstractions and for static abstractions. Another phenomenon that 
occurs only for dynamic abstractions is that sometimes It is necessary to consider the operations 
of the subordinate types in the correctness proof, as well as the operations of the principal type. 
The operations of any mutable subordinate type must be considered, since they can modify thf < 
system state, and since the simulation relation (usually) depends on the system state. The 
operations of static subordinate types need not be considered, because they cannot change the 
system state or return objects of the principal type, ^ince aA of the subordinate types of a static 
abstraction are static, the operations of the subordinate types of any statte abstraction need not 
explicitly^ enter into the correctness proof. 

Any interactions between the observable behavior of a mutable data abstraction and 
the operations of its mutable subordinate types depend on the mutation of shared data objects. 
Stnciethe subordinate relation on models is a weH founded partial order, it is not possible for 
any of the operations of a subordinate type to operate directly on any object of the principal 
type It is possible' for ah object x dfa subordinate type to share some substructure with an 
object y of trie principal type, so that tne externa^ observable behavior of y can depend on the 
state of x. Seating of this kirid can occur by cb^ In the first case, 

some primitive operation takes x at an argument aha incorporates it into j, where either y is 
passed as an argument to the operation or created by the operation and returned, fri the second 
case, some primitive operation taies j as an argument and returns the component x. 

For ah example of a case %here an mteract^wRri the operations of a subordinate 
type is possible, consider the 4 rtistt abstraction described as follows! %fits are mutable sets, with 
the usual set operations, and also an elments operation that returns an array containing the 
elements of the set In th%standard model, tiw fleets ifen^ nkurm * newly created array. 



- 119 - 

without affecting the state of any mset. Consequently, a subsequent assignment to some element 
of the array returned by the elements operation does not affect the contents of the mset from 
which the array was derived. An implementation in which such an assignment did affect the 
contenfs of the mset would not be behaviorally equivalent to the standard model, but the only 
way to detect the difference is to perform an arrayjstore operation, which is an operation of a 
mutable type subordinate to mset. (Such an incorrect implementation of mset is plausible, 
since it would arise if the programmer chose to represent msets as arrays, and in implementing 
the elements operation forgot to return a copy of the array representing the mset, rather than 
the representation itself) For such an incorrect implementation, it would not be possible to 
prove that the arraytfstore operation preserves the simulation relation, even though it could be 
possible to show that every operation of the principal type does preserve the simulation relation. 

5.4.1 Simple Example 

In this section we present a proof of correctness of an implementation of the unlque_ld 
abstraction. This is just about the simplest possible data abstraction that requires a state 
machine model. Recall that unique^ids are immutable, but they can be dynamically created. 
The standard model for the uniquejd abstraction is repeated for the reader's convenience in 
Figure 18. An implementation of unique_ids in terms of arrays is shown in Figure 19. In this 
implementation, we are taking advantage of the fact that arraylcreate always returns a new 
array (one that has not been used yet in the current computation). The implementation 
depends only on the identity of the array, so that the contents of the array can be changed 
arbitrarily without affecting the correctness of the implementation. A newly created array has a 
length equal to zero, and a specified lower bound for the indices. The standard model for 
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Flgure 1». Standard Model for Uniquejd 

type unique jd -m&V 

wrttn create: ~* U 

equal: U x U — > boolean 

data states D - { null } 

operations crcate(sX) - extend<s, null) 

«l*Mf^y)t'<$ t v> 
where v - if tokenlequaKx, y) then true else false 

end unique Jd 



Figure 19. Implementation of Uniquejd 

representation array tint] 

operations create() - array[int]tcreate<I) 

equaKx. y) - array[intttequaKx, y) 



arrays ft shown in Figure ft in Section 5.32. The pnwf of correctness is shown below. As 
before; we wiH prefix options, objeas. and stages belonging to the implementation with a "4" 
to distinguish them from their counterparts Irt the standard model. 



To prove that uniquejd and i uniquejd are behaviorally equivalent. 

Proof by induction on tht length of the computation: 

Assuming the simulation relation R holds for ail computations C such that I < length(C) < N, 

show that R holds for afl O such that WigthfO- N. 



Let s, sO, si be system states for uniquejd, 

4s, isO, Xsl be system states for iuniquejd, 

x, xl, y; i be uniquejd s 

4x, 4x1, 4y, 4z be iuniquejds 

b, 4b be booleans. 

Let R ex ** tx &• s ** is '*=> usetKx, s) s used(4x. 4s) 
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Sc x o ix & y « iy => (x = y) = (ix = ly) 
& b ♦♦ ib => b - lb 

Proof by cases on the name of the last operation in C. 

Case 1: create 

Let sO « isO. 

Let unique_id$create(sO)() = (si. xl> and iuniqueJdtcreate(lsOX) » <Asl, 1x1), 

so that si <-> Isl and xl *-> Jxl. 

By the definition of uniquejdjkreate, stateJtextend, and statelused, 

used(xl, si) & -• used(xl, sO) 

and used(z, sO) h used(z, si) for z * xl. 

By the definition of arrayJcreate, statelextend, and statelused, 

used(ixl, lsl)fc -usedUxl, IsO) 

and used(lz, IsO) s used(iz, Isl) for Iz * 1x1. 

Soz« Iz =* used(z, si) s used(lz, Isl) for any z, Iz. 

So the first clause of R is established for si, Isl. 

(lemma 1) if z * xl and z « Iz then Iz * 1x1: 
used(lxl. Isl) & - usedUxl, IsO), 

but used(Jz, Isl) = used(z, si) = used(z, sO) = used(lz, IsO), 
So Iz * 1x1. 

(lemma 2) if z = xl and z ^ iz then Iz - ixl: 
Since z = xl, used(z, si) &■ - used(z, sO). 
By the first clause of R, used(lz, Isl) & -> used(lz, IsO). 
used(lz, IsO) = used(lz, isl) for Iz * 1x1. 
So iz = ixl. 

Let x « ix and y «-» ly. 

Case 1.1: x * xl, y «* xl 

By lemma I, Ix * ixl and ly * lyl. 

So x h ix and y « iy in the prefix of the computation C. 

So the second clause of R holds by the induction hypothesis. 

Case 1.2: x = xl, y * xl 

Then x * y. 

By lemma 1, ly * ixl 

By lemma 2, Ix - ixl. 

So Ix * iy and the second clause of R holds. 
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Case 1.3. x * xl, y = xl 

Similar to Case 1.2. 

Case 1.4: x - xl, y - xl 

Then x - y. 

By lemma 2. 4x - Ixl - iy. 

So the second clause of R holds. 

The third clause of R holds since create and kreate do not return any boolean values. 

So R holds. 

Both create and kreate always terminate in £he norniat condition. 

Case 2: equal 

Let sO <* IsO, xO « 1x0, and yO ♦♦ iyO. 

Let equaKsOXxO, yO) = <sl, b> and iequaKisOXixO, iyO) - <isl, ib>. 

By the definition of equal, si ■» sO and b = (xO - yO), 

By the definition of iequal. isl - IsO and ib s (4x0 » iyQ^ , 

Since R holds In sO. (xO - yQ> = (AxQ ,.p iyOLso b « ib, and R boWs. 

Both equal and iequal always terminate in the normal condition. 

So « preserves termination conditions and truth value*. 
Therefore unique Jd and kiniquejd are behavioraily equivalent. 

The most important property of a unique Jd is that it is unique. This js expressed by 
the second clause of the simulation relation R, which says that two unUiutJL£% have the same 
representation if and only if the abstract objects they represent are Identically the same. The 
third clause of R is just the standard requirement on boolean values, Jrom which- the behavioral 
equivalence of the two models follows easily. The only operation at, untytw_irf that produces a 
boolean value is equal, and for that case the third clause of R follows easily from the second 
clause and the definition of equal. Establishing the second clause is harder, requiring the 
addition of the first clause to the simulation relation, to strengthen the induction hypothesis. 
The first clause is based on that fact that corresponding objects in the implementation and in 
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the standard model are created at the same time, so that either both exist (in states after the 
abstract object has been created) or both do not exist (in states before the abstract object has 
been created). Since the object returned by uniquejdfcreate is always newly created (and hence 
distinct from previously existing objects), and since only one object at a time is created, the 
unique representation property is preserved. 

The proof shown above is a typical example of the argument used to establish a 
unique representation property, treated in detail. Similar properties will be required in later 
examples, and we will sketch the proofs without filling in all of the details, assuming that the 
reader can adapt the argument given in this section. 

5.4.2 Typical Example 

A simple example of a proof of correctness for a dynamic data abstraction is presented 
in this section. We have adapted the intset example from [18], without incorporating the bound 
on the size of a set.' A standard model for intsets is shown in Figure 20. Intsets are mutable 
sets of integers. The empty operation creates a new intset, which is initially empty. The insert 
operation inserts a given integer into a given intset, returning no values and changing the state 
of the intset. The remove operation removes a given integer from a given intset. The has 
operation tests to see if a given integer is a member of a given intset. 

An implementation of intsets in terms of arrays is shown in Figure 21. This 



I. If sets with a bounded size are desired, then an exception conditions should be associated 
with the insert operation to indicate when an attempt has been made to exceed the size bound. 
This will add another case to the proof without further illuminating the methodology, and 
hence is omitted. 
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Figure 20. Standard Model for Intset 



type intset as I 



with 



data states 
restrictions 
identity 

operations 



end intset 



empty: — * I 

insert: I x int —> 

remove: ! x int -* 

has: I x int — > boolean 

D - setfint) 

none' 

settequal 

cmpty(sK) - extend(s, setlnulK)) 
insert($Xx. i) - updates, settaad{i,s(x))) 
remove(sXx. I) - urxlate<s, setfremoveO, i(x))) 
has(sXx. i) - <s, setirnemberft i(x))> 



Figure 21. Intset Implementation 

representation intset - arrayfint) 

restrictions a suth that low<a) - I ft ( low(a) < j , k < high(a) ft j * k 

identity arrayiequal 



operations 



definition 



a(|)*a(k)) 



emptyO ~ arrayEint)tcreate(l) 

insert(a, i) = if '"-• has<a, i) then addhfa, i) 

remove^, i) - if has<a, i) then { »ore(a, ftndja, i). athigh(a)] ; remh(a) } 

has(a, i) - if 3j[low{a) < j < higfofa) ft atjj-i) then true else false 

find(a. i) - if 3j( a[j] - i ] then j : atjj - i else 



implementation keeps at most one instance of any given integer in an array, but the order of 
the elements is arbitrary. The standard model for arrays is shown in Figure 15 in Section 5.3.2. 
The proof of correctness is shown below. An explanation follows the proof. 
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To show that intset and I intset are behaviorally equivalent. 
Proof by induction on the length of the computation: 
Assuming R fc I for all computations C such that 1 < leng<h(C) < N, 
show R fr I for all C such that length(C) = N. 

Let s, sO, si be system states for intset 

is, IsO, J si be system states for iintset 

x, xl, z be intsets 

ix, 1x1, Iz be iintsets 

i, il, ii, Ail. k, n be integers 

b, bl, lb, lbl be booleans 

Let R s Is « s fr 4x « x fr li « j =» ( j f s ( x ) = 3j[l < j < «(is(ix). e) & ii - is(ix). e[j]] ) 

fc ib ** b => ib = b 

Let I = is(lx).low = 1 & ( 1 < j , k < •(ls(lx). e) & j * k => is(ix). e[j] * is(ix). e[k] ) 
R is the simulation relation and I is the implementation invariant. 
Proof by cases on the name of the last operation of C. 
Case I: create 

Let isO *» sO, icreate(lsOX) - <isl, lxl>, create(sOX) = <sl, xl> 

Then we have isl ** si and ixl « xl 

By the definition of create, sl(z) = sO(z) for z * xl 

By the definition of icreate, isl(iz) = isO(lz) for iz * ixl 

So R and I hold for s •= si, is = isl, x * xl, ix * ixl 

For x = xl and ix = ixl we have 

sl(xl) - setJnulK), so i c sl(xl) is false for all i. 

isl(ixl) = (low: 1, e: <», «(ls(ix), e) = 0, and I < j < is false for all i. 

So R holds for the pair of states si, isl. 

isl(ixl). low = I and I < j , k < is false, so I holds. 

« preserves termination conditions since both create and icreate always 

terminate in the normal condition. 

Case 2: insert 

Let sO ♦* isO, xl « ixl, il « iil. 

Let insert(sOXxl, il) = si, iinsertflsOXlxl, iil) = isl. 

Then si « Isl. 

We have s0(z) = sl(z) for z * xl, and similarly for IsO, 

so we have to show R and I only for x = xl, ix - ixl, s - si, is = isl. 

By the definition of insert, sl(xl) = s(Xxl) U { il }. 
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Case 2.1: il < sO(xl). 

Then sKxl) = sO(xl), and hence si «sO.,.,, 

Since R holds in sO, 3jCI < j < *(4s0(lxl). e) * 4sO(4xl). e(j] - 4111 

So J-sl - isO by the definition of linsert. 

So R and I hold by the induction hypothesis. 

Case 2.2:-- il ( sO(xl). 

From R in sO. - 3jCl < j < »<4s0(ixl). e) & 4s0ttxl).*$« 4*tt 

From the definition of 4insert, 4sl(4xl) - (tew. I, e 4s0(4xl). e |» 4i>. 

3j[l < j < «(lsQ(lxl).j8)|bis0axDUer4)|.,Aii]»E ; 

3j[l < j < •(IsKixl). e) - 1 ft isKJfxl). e{j] - 411} 

and JstUxl). e(j] « 41 for j - «(4sK4xl). e). 

so R holds in si. isl. 

From the definition of iinsert, 4s(4xl). low - I. 

I holds for I < j , k < •asO(i^lM)^<KWrtM)^ I by the induction hypothesis, 

and I holds for I < j < k - «(4sK4xl). e), ' ' . 

since-3j{l<j<«(lsO(4xl).e)*is<XAjiH^|i-*ai - 

So I holds. 
** preserves termination conditions since both insert and 4insert 
always terminate in the normal condition. 

Case 3: remove 

Let sO ♦* 4s0, xl ** 4x1, il ♦♦ 4tt, 

Let removefcOXxl. il) « si. 4removet4sOX±xl. 4H) - UL 

Then st ** 4sl. 

We havesCKz) - sl(z) for i * xl, and similarly for 4j0, a 

so we have to show RanjiJ only for * * xltatx * 4x1, $ *4,4s « 4s4. 

By the definition of remove! sKxl) - sO(xl) - { Itji - -n 

Case 3.1: il c s<Xxl) 



Since R holds in sO. isO , 3j£l < j < .(480(4x1). e) & 4sO(ixl). efj] - 4il] 
Choose n such that I < n < t(4s0(ixl). e) fr 4sO(4xl). e|nj - 441. 
I holds in sO so n is unique and n - find(4sOX4xl, 4il). 

Case 3.1.1: n = •(ls0(4xl). e) 

Then from the definition of iremove, 
isl(ixl) ._- <tow: I. e: 4sO(4xl).e[l..i|-l3> 
From I with k - n and the previous hoe, 
- 3jCl < j < *(4sl(ixl).e) fc 4sK4xl).e(j] - 4iU 
so R holds for i - il. 
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Since Isl(ixl). e[kj - isOOxl). e(k] for 1 < K < n, 

for i * il, 3jtl < j < .(Istfixl). e) fc"isO(ixl). «$- ii] s 

3jtl < j < .(tsl(ixlj. ef& &KWc% efjl « % 
So R is established in si, isl. 
I in J si follows from I in isO. 

Case 31.2: n * •(isO(txl). e) 

THen from rtie definition of kerhbve. ' 
Jsl(lxl) = <low : 1, e: qtl.n-11 |» ^•oJ*lj[n«L«q-l]> r 
* where q « isQfjM^-e. 
From I with k = n and the previous line,. 
- 3jfl < j "< •tlsl(ixl). e) & tsKixl). efj] = iilf 
so R holds for i = il. 

Since isKi*l). eft] = ^ lsO(lxl). (ttfor f ^ I < n - 1 and n ♦ | < k < »q - 1, 
and islOxl). etn) - lsO(ixlKeI«ql , 
for i * it ljfl < j < •(Js5(ix0. e) & isO(ixl). e(j] « ii] h 

3|1 < j < #(lsKixl).e) * isKixl).efj] •? ill 
So R is established in si. isl 
I in Isl follows from I In isO. 

Case 3.2: -■ il ( sO(xl) „ 

Then sKxl) = sO(xl) - { il } * sO(xl|,so sj - sO. .......... 

Since Rhc^sirtsO, - 3jD S j < •UsOCtxl). e) * isutlxt). eTjl - Ml " ' 

so isl = IsO, by the definition of iremove and ihas. 

So R and I hold in si. isl. 
*+ preserves termination conditions since both remove and iremove 
always terminate in the normal condition. 

Case 4: haV 

Let tO ** isO. xl « ixl. jl *♦ iil. 

Let hasfcOXxl. il) = (si, bl>, ihas(isOXixl, iil) - <isl, ibl>. 

TfteW* Inland W*> m ! " 

From the definitions of has and ihas, si.- $0 and isl - isO, 

So I holds ■■' i: *^ "' 

We need to show that bl = ibl. 

By th#detlhitidf?«f ha$:bl - II c skxf). 

By the definition of ihas, ibl « 3jll < j < «<isO(ixl). e) & isp(ixl). efj} - ill 

By the fira clause of R.bl *lbi: ^ * - j 

« preserves termination conditions since both has and ihas always 

terminate in the normal condition. 

Since ** preserves termination conditions and the simulation relation. 
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all computations are eqtiifeasibk in intset and in iintset, and each ■..,..' 
computation producing a boolean value produces the same vahiftn both models. 
So intset and lintset are behavioralty equivalent 

The only primitive intset operation that can produce a boolean, value is has, and the 
relationship required for the has operation to give the same resufcs in both; models is expressed 
by the first clause of the simulation relation 8. The implementation invariant I expresses a 
restriction on the implementation strochires ,^t must be mainbii^ by the operations of the 
implementation. Note that the implementation invariant does not mention any objects of the 
standard model, in contrast to the simulation ration, which b (Goocejrned with the relations 
between the two models. The implementation iQvatiant says that all of the elements of the 
array representing an intset must be distinct, and that the tow bound of the array must be 
always equal to I (recall that arrays can grow and shrink from both ends). The implementation 
invariant is needed in the proof to show that the r rwayi operation, spresejves . the simulation 
relation. '■.['■.'•■ ...] r? -,.'. 

Whenever there is a state transition caused by thj> invocation of an operation of the 
state machine, we have to reestablish that the properties required for our proof of correctness 
are still true in the final state. There can be no simple general rule for transferring properties 
from one state to the next, because there is no simple syntactic rtlatioo between^ the text 
specifying an operation and the set of data objects that can be affected by the, operation. In 
general, the effects of an operation are not limited, to the dafc^objects that are, passed as 
arguments to the operation, because the data state of an object can contain other data objects, 
which in turn can have data states containing stiH more data objects. An invocation of an 
operation can potentially affect every object in the reachability closure of the arguments, which 
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can vary from one state to the next. Consequently we must establish the invariance of 
properties of data objects with respect to state transitions on a case by case basis. 

As can be seen in the proof above, explicitly arguing that each property is transferred 
from one state to the next need not lead to unmanageable complexity. In a correctness proof we 
are typically trying to show that the simulation relation and the implementation invariant 
remain true in spite of any state transitions that may be caused by the operations of the data 
abstraction we are trying to verify. In the example above, the arguments are very simple, since 
there is no potential for data sharing between intstts. In the example shown in the next section, 
there is potential sharing among the objects of the principal type, so that the arguments 
required to show that the simulation relation is preserved by a state transition have more 
content. 

5.4.3 Sophisticated Example 

A sophisticated example, consisting of the nonstandard implementation for mutable 
lists discussed at the end of Chapter 3, is presented in this section. This example treats a 
mutable abstraction whose objects may share subcomponents. The implementation is not 
reduced, so that more than one object (token) in the implementation may represent the same 
abstract mutable list. The standard model for mutable lists is shown in Figure 22. The 
implementation model for mutable lists is shown in Figure 23. We have defined the 
implementation model in the same notation as the standard model in order to keep the example 
as simple as possible. Strictly speaking, this example shows a proof of the behavioral 
equivalence of two models. The proof of correctness is outlined below. The proof for the cdr 
operation is very similar to the proof of the car operation, and similarly for rplaca and rplacd. 



-130 



Figure 22. Standard Model for Mutable Lists 
type list as L 



with 



data states 
restrictions 
identity 

operations 



nil: 

cons: 

car: 

cdr; 

rplaca 

rptacd: 

«1 : 



->L 

Lxi.-»L 

fc -* L ♦ < no.car : > 

i^t* <nojcdr:> 

L x L — > L ♦ < nojcar : > 

L x li — *r L ♦ <- nsjrir : > 

L x L — * boolean 



end list 



D - oneof[null: { ni) }, pair: tupleCh L, r: LU 
none ; ,,- ■ 

tokeniequal 

niKsX) - state[D]textend<s, nil in null) 

consUX*. y) - "a««{Djl«xtcod(s, 0: x, r: y) In pair) 

car(sXx) - if isfpairXstx)) then (s, totpalrJ(s<x)). I) 

ebe<no_car :s> 
cdKsXx) - if is[pairXs(x)) then <s, to(pair)(s(x)). r> 

else <no_cdr : s> 
rplaca(sXx, y) - if is[pairXs<x)) ,>?q 4 }tK.\'I ^ ^ 'ik { . -...--« 
then <state[D)tupdate(s. x, <l: y, r: to{pairXs(x)). r> in pair), x> 
else (no_car: s> 
rplacd(sXK, y> - if iitpairKs4x)) 

then <statetDBupdate(s, x, <l: to[pairXs(x)). I, r: y> in pair), x> 
^ ejpe <ncu*rfr>5S> <■■ -r- } rrH hi - 
eq<sXx. y) - tokentequaKx, y) 



so that only one proof is given for each pair of opjrottoni, and the other Is left to the reader. 
An explanation is given after the text of the proof, 



To show that list and Hist are behaviorally equivalent. 

Proof by induction on the length of the computation: 

Assuming R holds for all computations C such that I 5 length(C) < N, 

show that R holds for all C such that tenglMG) - N, 

Let s, sQ» sl be system states for list, 

Is, isO, isl be system states for Hist, 
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Figure 23. Implementation Model for Mutable List* 

data states D » cell[oneof[null: { nil }, pair: tupletl: L, q LIB 

operations niKsX) - state[listltexten^ate{^f^i%p[^ : i(il| in hu% 

con$(sXx. y) - state[list]textend(stat^a^fl^tiS>d(s, <1 xf f • fi In pajr}) 
car<$Xx) - if islpairXs<s<x)» ' -" ' " l f 

then <s, totpairXs(s{x)». I> 

eke (nojcariy 
cdr(sXx) - if islpairXsWxB) * 

^famtitt *' •* ' '••" " '■'•■"'"' : '■ 

rplaca(sXx, y) = if is[pairXs(s(x)) 

then state{listHextend< 
statefceHXhipdate( 
s. s($ <1: y, r: tofp%irts&x)ft. r> In pair ), 

■ "'^fy^^-'- ■-■ - -^- '•'- ■•• " 

else <no_car: s> 
rplacd(sXx. y) - if islpairXs^xj) 

then statey1s^K^d( ' ' 
'"'""•/" '" , statftcetOfupdaiK ; -' ; " 

imtii^iitfiMi®)' X ti y> in pair ). 

etse'<no_cdf:*> ! 

eqdXx.y) - tokera^ua^xX^f)) 1 



w, x, y, z, xO, yO be lists 
iw, ix, iy. iz, ixO, iyO be ilists, 
b, ib be booleans, 
ic be a cell. 

Let R = ( x « ix & s « Is & is[nu«Xs(x^ -* istrtatJXistts(Jx)) ) 
& ( x « ix 8c s » is * is[pairXs(x)) ■»*■ idpairXis(is(ix))) 

*stxW4tfi#xj).i 

r$fl)/r rt ii<i^x)). r ) 
& { x «+ ix & y «+ iy & s * is "» (x * s y) W^fix) <•" 

Mb«ib=*>b-ib> ^3et v U < - 

Proof by cases on the name of the last operation of C. 
Case I: nil 

Let sO « isO. 
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LetniKiOX)-'<sl.w>and4niKisOX)- r <id.4wX ' 

Then $1 «+ isl and w «+ iw. 

sl(z) - sO(z) for z * w, and similarly for isl. 

So we need to show R^ry ^ x - w t lx - iw. „, 

By the definition p( nU. isfnuM&Kw)). 

By the defiriition of iniUstnuflXisKUKw))). 

So the first clause of R holds. 

The second clause is trivially true for x - w, ix » iw 

since the hypothesis of the implication is false. , 

Since w and isKiw) are newly created, the tbi^j clause gf^ holds. 

Both nil and inil always terminate in the wofy^cnflfttitin, 

,: -;■■ /■U\s,: V t: ;s - • . <- ■-.;■- ■■: ■>... 

Case 2: cons 

Let sO « isO, xO « i*0.jO,*» iyO, 

Let cons(s0)6c0, yO) - 4f.w) and lconsUs0jfyxQ,4y0) - <isl, iw>. 

Then si *» isl and w ** iw. 

sl(z> - sO(z) for z * w, and similarly for f si. i 

So we need to show R only for x - w, ix.* iw. 

By the definition of cons, is[pirj(s|(w)^wj. I - xO, and sKw). r - yO. 

By the definitioRpf^coB^^rlifl^^ i*KisKiw)). I - 1x0. and isKisKiw)). r - iyO. 

The first clause olF R U frivialy true? ' f 

Since xO ♦♦ ixO and yO ** iyO, the second clause of R holds. 

Since w and isKiw) are newly created, the third cbu^ of R hoMi. 

Both cons and icons always terminate in trw non^ri condition. 

Case 3: car 

Let sO « isO and xO ♦♦ 1x0. 

Case 3.1: is[pairX$0(xO)) 

/ 
Let caKsOXxO) - <sl, w> and kaKitQXixO) « asl,iw>. 
Then si « Jsl and w ♦♦ iw. 
By the definition of car, si - sO and ¥ - s0(x6). I. 
By the definition I of leaf, is| !?is|,a$d iw - is0(is0(ix0)). I 
Smcesl « sOandiU • itO, R\hokJsiRs|, isl#or x.y * w. 
Since R holds in $0, isO, is[plirX4s6(isb(ix6))) and $0(x0). I h ia0(i«0(ix0». L 
So w «+ iw for the prefix of C. 

So R holds for si, isl. . ■,- 

Both car and icar terminate in the normal condition for this case. 

Case 3.2: is[nullXs(XxO)) 

Then since R holds in sO, is[nullXisO(isO(ixO))). 
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Let car(sOXxO) - si and karUsOXixO) - ill. 

Then si ♦* isL 

By the dcfinitiw of car and kar, si - sQ and isl - kQ, so R holds 

Both car and kar terminate in the no_car condition for this case. 

Case 4: cdr 

Similar to Case 3, proof left to the reader. 

Case 5: rplaca 

Let sO ♦•♦ isO, xO « 1x0, and yO«*iyO. 

Case 5.1: is[pairXsO(x0)) 

From R, istpairXlsO(lsO(ixO))). 

Let <sl, w> = rplaca(sOXxO, yO). 

Let <isl, Iw) = rplaca(lsOXlxO, iyO). 

Then si ♦* I si and w « iw. 

By the definition of rplaca, 

sl(z) = sO(z) for i * xO = w. 

By thedefinijtion of irpjaca,^ 

ktfiz) = isOUz) for Iz * iw and isl(k) - isO(k) for k * is0(iw) - is0(ix0). 

R hoWsJn sO, isO, and frorO|the third clause of R, 

z « iz fr z * xO => Is0(iz) * IsOOxO). 

So lsl(Jsl(U)) = ,isp(isO(iz»for ii* %* x& 

So R holds for x * xO. 

The first clause of R holds for x - xO - w since - 1 is[nullXsl(w)). 

From the definition of rplaca, w - xO. 

From the definition of kplaca,JsKiw)^4*0(lxO), 

and isl(iz) « ls0(iz) for Iz * iw.' 

So the third clause, of R in si, isl jfoUows,from R in $& is0. 

FrOm the definition of rplaca, sl(w) - <l: yO, r: s0(x0). r>. 

Suppose x = xO = w. 

Then from the third clause of R, 

x ** 1 x =■> isl(4x) .- ,kl(iw), and ^sKisKlx)) „ IsUisKiw)). 

From the definition of Irplaca, is[pairXisl(isl<iw))) and 

islUslUw)) - <J: IyO, r: isOUsOUxO)), r>. , 

We have yO ♦+ iyO, and since R holds in sO, isO, 

s0(x0).r*is0(is0(ix0)).r. 

So the second clause of R holds in si, isl. 

So R holds. 

Both rplaca and Irplaca terminate in the normal condition for this case. 

Case 5.2: is[nuliXsO(xO)) 
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Let rp1aca($OXxO, yO) = si and lrpbca(is9X*xO. iyO) - tsl. 

By the definitions of rptaca and Irplaca, sO - si and isO - 1st, so R holds. 

Both rpteca and irplaca terminate in the nb.car condition fcr this case. 

Case 6: rplacd 

Similar to Case 5, proof left to reader. 

Case 7: eq 

Let sO **H0, xO « ixO, and yO « iyO. 

Let eq(sOXxO, yO) - <sl, b> and leq(lsOXlxO, iyO) - <lsl, Ao). 

By the definition of eq, si » sO and b s (xO « yO). 

By the definition of leq, Isl - IsO and lb s <lsO(xO) - Is0(y0». 

Since R holds in sO, xO « 1x0, and yO ** IyO, (xO - yO) a (Is0(ix0) - l$0(iyp)). 

So b - lb, and R holds. ' < 

Both eq and leq terminate in the normal condition. 

So list and Hist are behaviorafly equivalent. 

The mutable list example was chosen to illustrate several issues arising from the 
sharing of mutable data objects. Since wehave made a strkt distinction between the identity of 
a token and its state, there is no notattonal difficulty fh stating that one object is a 
subcomponent of the states of several other objects (ie, that the first object is shared by the 
latter objects). Note the use of the correspondence relation «* in the conclusion of the second 
clause of the simulation relation R. to indicate that the identities of the components of a 
non-null list must correspond in the two models. 

The example illustrates a case where there may be many distinct representations for 
the same mutable object. Every time a rplaca or rfdoed operation li performed oh a list, a new 
representation object for that list is created in the implementation. Despite the multiple 
representations, the externally observable behavior of mutable lists is correctly realized in the 
implementation, so that the non-uniqueness of the representation used by the Implementation is 
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not externally observable. Whenever the state of a list is modified by a rplaca or rplacd 
operation, the change is reflected in the states of all of the representations for the abstract list 
that was modified, and not just in the particular representation that ii returned as the result. 
This is accomplished by introducing an extra level of indirection: the state of a list in the 
implementation model is a cell containing the abstract state of the list. In our notation, if s *+ Is 
are two corresponding states and if x « ix are two corresponding lists, then the abstract state 
s(x) corresponds to the concrete state is(ls(lx)), where ls(ix) denotes the identity of the shared 
cell. The cell is shared by all of the representations of the same abstract list, and all of the 
relevant state information is contained in this cell, so that any state changes are automatically 
reflected in all "copies" of the list object. The eq operation computes the identity relation on 
abstract lists, rather than the identity relation of the implementation model, which is not 
externally observable. The identity relation on abstract lists is described by the third clause of 
the simulation relation R. Note that the implementation depends critically on the fact that the 
data state of a token representing a list (the identity of the shared cell) never changes, although 
the data state of the data state of the token (the contents of the cell) may change. It is easy to 
check that this property is maintained, since none of the 4-tist operations applies a statetupdate 
operation directly to a token representing a list. 

The interesting part of the proof is case 5.1, where the normal termination of the state 
changing rplaca operation is treated. Note the use of the third clause of the simulation relation 
R to implicitly describe the set of representation objects affected by the operation. 
Implementation objects other than those passed as arguments can be affected by a rplaca 
operation, due to the shared mutable cell in the state of a list in the implementation model. In 
the argument to establish that the rplaca operation does not damage the simulation relation for 
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objects other than those passed as arguments, the relation given by the third clause of R is used 
to distinguish between the set of objects that is supposed to be affected by the operation from 
those objects that are not supposed to be affected. It is just as important to establish that all of 
the objects whose states are supposed to be affected by the operation reflect the change as it is 
to show that the objects that are not supposed to be affected retain their previous properties. 

White it may be difficult to derive a description of the set of objects that is supposed 
to be affected by a given operation from an implementation of an arbitrary mutable data 
abstraction, it is important to make this set explicit, because errors stemming from hidden 
interactions due to unintended sharing relations are very difficult to track down. The designer 
should therefore pay explicit and careful attention to the characterization of the set of data 



:,if?<C£f. 



objects that should be affected by an operation during the design of the implementation. The 
intended restrictions on the sharing relationships should be written down as part of the design 
process, for later reference and for possible use in proofs. This suggestion is analogous to the 
suggested practice of developing loops together with the associated loop invariants. The 
suggestion is motivated by the fact that the required information must be informally considered 
by the designer anyWay, and that It is easier to formalize a familiar but informal notion than it 
is to derive the required properties from an unfamiliar implementation. 
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6. Conclusions 

In this chapter we review the concepts central to this work, present a comparison of 
the algebraic and abstract model specifications, and suggest some directions for future research. 

6.1 Central Concepts 

We have been concerned with treating potentially shared mutable data. This 
orientation has lead us to adopt an object oriented viewpoint, and to define the correctness of 
an implementation of a data abstraction in terms of the behavioral equivalence of the 
implementation and the standard model. To prove the correctness of an implementation, we 
have found it necessary to replace the representation function introduced by Hoare [18] with the 
simulation relation. We have also found that a form of computation induction is an 
appropriate method for proving properties of mutable data abstractions. 

6.1.1 Data Objects 

In this work we have adopted an object oriented viewpoint, rather than the more 
conventional variable oriented view. This choice was motivated by our desire to treat shared 
mutable data. If there is no sharing of data, then a change in the state of a data object can 
affect at most one variable, and the change can be modeled as the assignment of a new 
immutable value to the affected variable. If data can be shared, then a change in the state of a 
mutable data object can affect arbitrarily many variables, so that the simplicity of the variable 
oriented viewpoint breaks down. 

In our approach, states are associated with data objects as well as with variables. A 
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mutable data object is modeled as a featureless token, which serves to identify the object. The 
value of a variable is a data object (or token|^ The vaMw of a variable is affected by 
assignment statements. The system state function maps each token into its current data state. 
For most mutable data abstractions all of the interesting properties of a mutable data object 
other than its identity are subject to change, and are represented "by the data state associated 
with the object by the currem system state function. The state of a data object of a given type 
can be affected by the primitive operations of the type. 

By introducing an extra level of indirection Jn our model, we achieve localized 
descriptions of operations that modify pojentially shared da^ta. If ^wo variables share the same 
data object, then they denote the same token, and any change in the data state of that token wttl 
be reflected in both variables. After such a state transition, both variables retain their original 
values, since the identity of the shared data object is not changed, but, the properties of the 
shared object are different in the new state. 

6.1.2 Behavioral Equivalence 

The concept of behavioral equivalence of models is central to this work. Two modeU 
are behaviorally equivalent if every computation results in [the same termination condition in 
both models, and if any computation with a boolean re$uk yiekls the, same value in both 
models. This formal characterization of the externally observable bthaviof of a model is 
intuitively satisfying, since it says that two models are behaviorally equivalent if they have the 
same externally observable properties. The characterization is also useful because it allows us to 
compare models with quite different internal structures. We have to exj»min< only thf names of 
termination conditions and boolean values to apply our definition of behavioral equivalence. 



-139- 
The representation of the objects of all other types is not explicitly mentioned, and can be 
different in the two models to be compared. System state functions are never explicitly 
compared, and it does not matter whether a model has a phylum of system states or not. It is 
quite possible for a state machine model (with system states) to be behaviorally equivalent to an 
exception algebra model (without system states). 

An implementation of a data abstraction is correct if and only if it is behaviorally 
equivalent to the standard model of the abstraction. We feel that this definition of correctness 
with respect to an abstract model specification is the right one to use, because it reduces to the 
classical one (existence of a homomorphism) for the case where both the standard model and 
the implementation model are static (see theorems 4 and 7), and because it applies also to 
dynamic models, whereas the classical criterion does not. 

6.1.3 Simulation Relations 

We have developed a method based on simulation relations for proving the 
behavioral equivalence of two models. The method can be used to prove the correctness of an 
implementation of a data abstraction with respect to an abstract model specification. The 
method is applicable to all models satisfying the assumptions set down at the beginning of this 
work, but it is most useful in the case where bath models are dynamic. Simpler methods based 
on correspondence functions and homomorphisms are available for the cases where one or both 
models are static, as described in Chapter 5. Simulation relations and correspondence functions 
were introduced because it was found that homomorphisms do not suffice for dynamic models. 

A simulation relation describes the relation that must hold between the representations 
and data states of corresponding objects in the implementation and standard models in order 
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for the externally observable behavior of the objects to be the same. To show that two models 
are behavioralty equivalent, a simulation relation is explicitly constructed, and it is established 
that the simulation retortion holds fbf alt reachable states by induction over all computation 
sequences. To establish behavioral equivalence, the simulation relation must imply that 
corresponding operations on corresponding objects result in the same termination conditions 
and boolean values. The simulation relation must also be strong enough to establish all of the 
properties of -the inputs that the operations depend on; so that the induction will go through. 

Simulation relations are defined hi terms of the correspondence relation «, which 
relates tire identities of corresponding data objects in the two models. ♦+ is defined in terms of 
the computation sequence, by Saying that the results of corresponding steps of the computation 
in the two models are related by *♦. Since the tokens of a dynamic model are anonymous, and 
since operations that create new data objects result in tokens unrelated to previously known, 
tokens, the only generally applicable method for establishing the correspondence is to appeal to 
the history of the computation. A simulation relation has the same purpose as a 
homemorphism, but it cannot be defined as a function in the dynamic case because of the 
dependence on the hiswry of the computation m the static case, a simulation relation would 
require that objects related by ♦* are homomorphic images, but since* there is no need to separate 
the identity of an object from its properties in the sfafic case, the homomorphism can be Used in. 
the proof drrectry, without introducing the » relation. 
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6.1.4 Proving Theorems about Data Abstractions 

In the main body of this work we have concentrated on proving the correctness of an 
implementation of a data abstraction with respect to a standard model specification. This is 
only half of the process requited to verify programs that use data abstractions. The other half 
of the process involves proving that the invocations of the operations of a data abstraction in a 
program written using the abstraction have the specified effect. 

The intended behavior of a program is typically described by giving assertions 
expressing the relations that must hold between the data objects manipulated by the program at 
various points in its execution For programs that use data abstractions, the assertions will be 
written in terms of the primitive operations of the abstraction. For dynamic abstractions, the 
system state must be explicitly included in the assertions, so that the operations can be treated as 
functions, and used without regard for the context in which they appear (i.e., there are no side 
effects in the assertion language). 

The problem of showing that a program satisfies its assertions can be reduced to the 
problem of proving theorems about the data abstractions it uses, by using an axiomatic 
definition of the control constructs of the programming language to eliminate the program texts 
from the correctness requirements. The theorems derived from the annotated program texts, 
which must be proved in order to establish its correctness, are called verification conditions. 
The process of deriving the verification conditions from an annotated program text has been 
extensively treated in the literature on program verification for the case where the data 
abstractions used by the program are well understood domains such as the integers. The 
process is not significantly affected by the introduction of static user defined data abstractions. 
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The introduction of dynamic abstractions raises the problem of introducing symbolic names for 
the intermediate system states, which are implicit in the program text but which are required in 
the assertions. This process will require a flow analysis of the program-. Previous work on 
automatic verification of programs operating on mutable data (51,32] has not explicitly 
introduced states into assertions, avoiding this issue. Whjle we have not investigated the 
problem in detail, we foresee no essential difficulty in producing verification conditions for 
programs that use mutable data abstractions. 

The problem of proving the verification conditions based on an abstract model 
specification presents no methodological problems, although just about any interesting data 
domain has theorems which are hard to prove. It is sufficient to prove *e interpretations of 
the verification conditions in the standard models of tht data abstracUons used by the program, 
since behavioral equivalence guarantees that all of the ground terms composed from th« 
primitive operations of the abstraction will have the same truth values in both the standard 
model and any behavioralty equivalent implementation model. Since quantifiers can be 
restricted to range over only the computable objects o| ^a. data abstraction, behavioral 
equivalence implies that any assertion will have the same truth values in both models. 

6.1.5 Compti tat ton Induction 

In doing the proofs of correctness of implementation in Chapter 5, we have used a 
form of computation induction to establish that the simulation, relation hoWs for all (reachable) 
objects and states of an abstraction. This technique is useful for proving properties of dynamic 
data abstractions, and performs the same function i as the generator induction j*rfe for static data 
abstractions. There are two essential differences between the two kinds of induction. 
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The generator induction rule requires us to show that all of the operations of a data 
abstraction preserve the property to be proved. To prove a property of the data abstraction d 
using the computation induction rate, we must show- that the operations of any mutable 
abstraction subordinate torf preserve the property, in addition to the operations of rf This is 
necessary because the operations of the mutable sebordtnfcte types can cause state transitions 
that can affect the truth of an assertion in vol viog objects of type rf<see Chapter 5) 

The generator induction rule requires us to show that the objects returned by each 
operation satisfy the property we are trymg to prove. The computation induction rule also 
requires us to show that all of the values resulting irorn each? operation satisfy the property we 
are trying to prove, including the n*w system state function that is an implicit resuk of each 
operation of a state machine. Since ihe system state function describes the current states of ail 
of the data objects in the system, we have te show that the property we are trying to prove 
holds in the new system state for att date objects, and not jest for the data objects that were 
passed as arguments to tbeoperation or that were returned as resuUs This is necessary because 
an operation can cause state changes in objects that were not passed as arguments, but which 
are reachable from the arguments > 



6.2 Algebraic vs. Abstract Model Specifications 

In this section we pomt but some of the relations'befween the abstract model and the 
algebraic specification techniques, amd present a criticafcompirlsonbetween the two techniques. 
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6.22.1 Relation of the Techniques 

The algebraic and the abstract model lechniqtses are botfcconcerned with specifying 
the behavior of a data abstraction, and hence both are deolwg with rto same cfcrss of 
mathematical structures, although there are slight technical di ffe re nces in the way in which 
different researchers define the class. Thereareseyeralw^kriown result* retating an algebraic 
specification to the class of models satisfying the specification. 

One of the main algebraic result* relevant to the algebraic specification technique f9} 
is a uniform construction of a canonical model for any axiomatiiation consisting of a set of 
equations, where the expressions on both sides -.srfv each equation are composed from the 
operations of the data abstraction. The model resulting from this construction is a quotient 
structure, whose elements are equivalence classes of expressions, where two expressions art 
equivalent if one is derivable from the other from the axwras in fmitety many steps This 
theorem establishes a connection between the proof theory of an algebraic specification and an 
algebraic model for the specified abstraction. The theorem ahows us to view an algebraic 
specification as a prescription for constructing a standard model tor the data abstraction that *r 
specified, so that an algebraic specification can be considered either as an axiomatization or as 
the definition of a standard model. 

Another important algebraic result is that the canonical model constructed as 
described above is an initial algebra in the category oi algebras sat^ffing the axioms (9J. which 
means that there is a homomorphism from the initial algebra to any other algebra in the 
category. In view of theorem 7, and the existence of the homomorphisms guaranteed by the 
initiality property, all of the elements of the category are behaviorally equivalent to the initial 
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algebra. In view of theorem 4, if the initial algebra is reduced, then there is a homomorphism 
from the initial algebra to every other algebra behaviorally equivalent to it, so that the whole 
category is an equivalence class with respect to behavioral equivalence. If we restrict ourselves 
to static abstractions and to axromatizations that define a reduced canonical model, then the set 
of all models satisfying the axioms is the same as the set of all models behaviorally equivalent to 
the canonical model, and our definition of correctness agrees with those used in the axiomatic 
approaches [37, 10, 9]. For the case where the canonical model defined by the axioms is not 
reduced, there is a lack of agreement on the proper definition of the set of implementations 
consistent with an algebraic specification [12, 9, 221 

6.2.2 Critical Comparison 

The criteria for evaluating specification techniques given in [31] are: (1) formality, (2) 
constructibility, (3) comprehensibility, (4) minimality, (5) range of applicability, and (6) 
extensibility. 

Both the algebraic technique and the abstract model technique as developed in this 
work are sufficiently formal, since both techniques have been given mathematical definitions. 

Both techniques result in minimal specifications. It has often been (incorrectly) said 
that abstract model specifications are not minimal, because the mode) may have Irrelevant 
characteristics. As our definition of correctness illustrates, only those properties of a model that 
are externally observable in terms of the operations of the abstraction are relevant, and those 
properties must be defined by any complete specification. Neither abstract model specifications 
nor algebraic specifications constrain either the representation structure or the algorithms that 
may be used by an implementation, as long as the externally observable behavior of the 
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abstraction is realized. 

From a less formal point of view, it could be argued that the abstract representation is 
not directly observable in terms of the operations available to the user of the abstraction, and 
that this introduces the burden of keeping track of which details are directly observable and 
which details are not, The axiomatic approach has advantages with respect to this criterion, 
since there is no explicit mention of the representation. It has been shown [52] that there are 
abstractions that cannot be axiomatized without introducing auxiliary functions. Since the 
auxiliary functions also compute values that are not directly observable in terms of the 
operations, axiomatic specifications can also have details that need not appear in an 
implementation. : : ; « ^ i - > 

Another argument that has been used to suggest that abstract model specifications are 
not minimal is that the abstract representation tends to suggest an implementation. This is 
possible, but concern with issues of time and space efficiency often requires that the 
representation used in an implementation differ significantly from the representation used in 
the standard model, which is usually the simplest structure that will exhibit the desired 
behavior. The abstract representation is often defined in terms of mathematical structures not 
directly supported by the host programming language, so that in many cases it is not possible to 
use the specification structure in the implementation. 

At the time of this writing, the abstract model technique has a clear advantage with 
respect to range of applicability over the algebraic specification technique, since it treats shared 
mutable data while the algebraic technique does not. We expect this advantage to be a 
temporary one. which wilt disappear as further research extends axiomatic specifications to 
apply to this domain also. 
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We have found abstract model specifications significantly easier to construct and to 
understand than algebraic specifications. This is a subjective impression based on our own 
experience, and we urge the reader to try both techniques and to form his or her own opinion. 
We conjecture that part of the reason for our experience is that the set of data objects is 
explicitly described by an abstract model specification, while it is implicitly defined by the 
interaction of a potentially large number of axioms in the algebraic technique. The result is 
that the operations can often be understood and defined one at a time and based on fairly local 
considerations when using the abstract model technique, whereas the interactions between a 
number of operations must be considered in the algebraic approach, requiring a more global 
analysis. 

We have found that abstract model specifications are significantly easier to modify 
than algebraic specifications, especially in the case where the meaning of one operation is 
changed but the meaning of the abstract representation is not changed, because only the 
operation that is changed need be considered. In an algebraic specification, every axiom that 
mentions the operation that was changed must be reexamined, and usually each operation is 
mentioned in more than one axiom. The effort of extending the specification of an abstraction 
by adding a new operation is roughly the same as that required to define an operation in the 
initial design, and again we have found that the process is easier using the abstract model 
technique. 

An algebraic specification can also be viewed as the definition of an abstract mode! 
whose representation is the word algebra, containing all of the expression that can be 
constructed from the names of the primitive operations For abstractions whose operations are 
relatively easy to define using this representation (i.e., syntax trees), the algebraic specifications 
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are relatively simple, white for other abstractions the operations may be quite awkward to define 
using this representation, and an abstract model using a representation algebra with a 
significantly different structure may be much simpler than the corresponding algebraic 
specification. From this point of view, the abstract model technique is easier to use simply 
because it offers a wider choice of representation structures to start from. By using the fixpoint 
construction to define a representation domain of syntax trees, it is always possible to define an 
abstract model with essentially the same structure as any given algebraic definition. 

Another criterion for judging a specification technique is the relative difficulty of 
checking whether a given specification is weH formed. If we are interested in using 
specifications in the design process, it is helpful for the process of constructing the specifications 
to point out inconsistencies in the design, or at least to make them easier to find. We would like 
ill formed specifications to be easy to recognize. 

To check that an abstract model specification is weH formed it is necessary to check 
that the operations are well defined functions, and that the operations preserve the constraints 
adopted when defining the model. For each operation, it is necessary to check that the results 
of the operation satisfy the invariant relation specified by the restriction* section of the 
specification. It is also necessary to check that each operation will yield equivalent results when 
applied to either of two data objects related by the equivalence relation defined by the Identity 
section of the specification. These properties are fairly easy to check informally, and they are 
generally not too difficult to prove rigorously. It is also usually fairly straightforward to check 
that the operations are defined for all inputs, and result in unique values. It is necessary to 
show that each invocation of an operation that can raise an exception will terminate in the 
expected termination condition, and that each recursive dentition and each iota expression (see 
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Chapter 4) is well founded Showing that a recursive function terminates is undecidable in the 
general case, but that seems to have little practical significance. In cases where something is 
wrong with the design, the designer will usually be unable to produce a function definition that 
even appears to be well formed. 

In the algebraic approach, there is no analog to the data invariant, and the 
equivalence is guaranteed to be consistent with the operations by construction (of the canonical 
model). If an attempt is made to define an operation that attempts to produce different value 
for expressions representing equivalent abstract objects, then the result will be an inconsistent 
axiomatization, where the multiple values are redefined to be equivalent. In such a case the 
subordinate types of the canonical model often collapse into singleton sets. Incomplete 
definitions introduce extra data objects into the subordinate types, which are produced by 
expressions that cannot be reduced to bona fide elements of the subordinate types by the 
axiomatic definition. Rather than leading to an easily recognized failure, the algebraic 
technique will typically redefine the previously defined types in cases where the basic design is 
flawed. 

Determining whether a given axiomatization is complete and consistent is generally 
acknowledged to be a difficult problem in modern mathematics, and there does not seem to be 
any straightforward procedure for checking the well formedness of an axiomatization. There 
are mechanical procedures for checking whether an axiomatization is complete and consistent 
that apply in restricted cases (the general problem is undecidable), but it is not clear whether 
these procedures can be used as practical aids in the design process. 

An advantage of algebraic specifications is that fairly powerful automatic theorem 
provers for algebraically defined data abstractions have been developed. This advantage is 
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be carried over to the abstract domain, leading to short and simple arguments. This 
phenomenon may have an analog for mechanical theorem provers, since special purpose 
theorem provers designed for the particular modeling domains used in constructing abstract 
models may be more efficient and more powerful than a general purpose theorem prover that 
must work with arbitrary axiomatizations. 

If proofs of correctness are to be used for certifying software, then it is necessary to 
develop mechanical proof checking procedures, because proofs developed manually are at least 
as susceptible to errors as programs written by people. While a completely automated theorem 
proving facility would be nice to have, it looks likely that in a practical system the theorem 
prover will need human guidance, perhaps in the form of an informal outline of a proof, which 
the mechanical procedure tries to augment until it either discovers a formal proof or an error. 

Our experience with proofs in terms of abstract model specifications indicates that an 
intuitive understanding of the model derived from familiarity with the underlying modeling 
domain often acts as a valuable guide to discovering a successful proof strategy. For axiomatic 
specifications this intuition is often lacking, and the process of trying to construct a proof 
degenerates into fairly blind symbol manipulation and syntax directed searching more often 
than for abstract model specifications. If the theorem pfover must rely on human guidance, 
then the ease of finding intuitive insights can be an important consideration. We also 
conjecture that the extra structure provided by the abstract model is useful in constructing 
heuristics to guide the search strategy of a completely automated theorem prover. 

In order to settle these questions, special purpose theorem provers oriented to the 
modeling domains used in abstract model specifications should be constructed and integrated 
into a program verification system. 
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Another question that is of interest is the extension of the framework developed here 
to incorporate nondeterminism and partial operations. Both of these extensions require a 
refinement of the idea of behavioral equivalence. 

If the operations of a data abstraction can be nondeterministk, then a computation no 
longer has a unique value, but rather a set of possible values. Strict equivalence of the 
behavior of two models would require that the set of possible results of a computation be the 
same in both models. Since a more deterministic implementation of a nondeterministtc 
operation is presumably correct if it always exhibits one of the possible behaviors for the 
standard model, an approximation relation that requires the set of possible results for the 
implementation to be a subset of the set of possible results for the standard model is a more 
appropriate metric for the correctness of an implementation, provided that the set of possible 
results is never empty. 

Some abstractions have potentially useful operations that are inherently partial 
functions. One example is the domain of expressions for a Turing complete programming 
language, with an operation for evaluating expressions. In order to develop a mode) for such a 
structure, some sort of provision has to be made for cases in which the operations do not 
terminate. The impact of such an extension on the rest of the theory should be investigated. 
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Appendix I - Assumptions and Restrictions 

1. Partial Operations 

The operations that can be defined in a programming language are in general partial 
functions, since there may be circumstances under which they do not terminate. We w.i4l require 
the operations of a data abstraction to be total, because we feel that it is bad programming 
practice to design abstractions with primitive operations that may fail to terminate. Some teem 
work on specifying data abstractions with partial operations can be found in £7]. 

Many data abstractions have operations that make sense only for somj? proper subset 
of the input domain (ie. dividing by zero is not well defined). If an operation is invoked with 
arguments that are outside its natural domain of definition, the operation should terminate by 
raising an exception, to indicate that something unusual has happened. The reader should 
note that it is possible to transform a computable partial function into a confutable total 
function that raises an exception only if the domain of definition of the partial function is a 
recursive set An interpreter for any Turing-complete language has a domain of definition *bat 
is not recursive (otherwise the halting problem would be decidable), demonstrating that there 
are interesting functions that cannot be made to satisfy our restriction. Partial recursive 
procedures that compute such functions can of course be defined in terms of the primitive 
operations of a suitable data abstraction, but we do not allow them to be included as primitive 
operations of the abstraction. 
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2. Nondetortninistio Operations 

We would like to distinguish between pa iMaUy sped**** operations ami 
nondeterministic operations. A partially specified operation is defined only for some proper 
sublet of its input type, and presumably the designer does not care what the operation does if It 
is presented With an input outside of that subset. We feel that k is bad design practise to 
produce specifications of this type, because of the possibility of undetected errors in the use of 
the abstraction. The only case in which we truly do not care what an operation does on a 
certain input is if We know that it will nevei be called with that input. A well designed data 
abstraction should raise an exception for all inputs for which no normal response is specified, so 
that attempts to use the operation outside of its domain of validity will not pass undetected. 

Data abstractions with nondeterministic operations are potentially interesting, but are 
not treated in the main body of this work. An operation can be described by an input output 
relation R, which relates the inputs of an operation to the legal output values for those inputs. 
For a deterministic operation, such a relation is single valued, and h in fact an ordinary 
function. Some operations are most naturally described by relations that are not single valued: 
the programmer wants the operation to satisfy certain criteria (eg. the relation R), and does not 
care if there is a unique result, or which valid result is actually chosen, if there is more than one 
valid choice. We do not recommend introducing extra constraints with the sole purpose of 
restricting R to the point where it becomes a function. Such constraints complicate the 
specification by introducing irrelevant details, and also may exclude some of the simplest and 
most efficient implementations, which would be perfectly acceptable Without the artificial 
constraints. 
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A non functional input-output relation R is consistent with a whole class of operations, 
some of which are deterministic, and some of which are not. The reader should note that it is 
quire possible to implement a data abstraction with nondeterministic operations on a 
deterministic machine, because an abstract data object need not have a unique representation in 
the implementation. For example, consider the data abstraction consisting of the finite sets of 
natural numbers, together with the usual set theoretic operations, and a choose operation. The 
choose operation returns an element of a given set if the set is nonempty, and raises an exception 
otherwise. It is not specified which element of the set is to be chosen if there (is more than one. 
Abstract sets are immutable, and two sets are equal if and only if they have the same elements. 
In an implementation, sets might be represented as linked lists, and the choose operation might 
return the first element in the list. However, since there are many^ different representations for 
the same set. with the elements stored in different orders, the choose operation appears to be 
nondeterministic when viewed as an operation on abstract sets. 

We know of no work that has been done on specifying data abstractions with 
nondeterministic operations. Some work on specifying nondeterministic operations in terms of 
relations is reported in [34]. 

3. Concurrency 

Concurrent access to data objects by parallel processes is an interesting subject that is 
beyond the scope of this Thesis. It is profitable to consider parallel processing in the context of 
data abstractions [20,16,6,38,24] because processes need to be synchronized only if they 
operate on shared data. Even though a quite a bit of work has been done in this area, the 
issues involved in specifying the correctness of a data abstraction in the presence of concurrent 
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mutation of data objects are not yet well understood. 

4. Exceptions 

Since there is no generally accepted model of exceptions and exception handling, we 
have chosen a point off view that simplifies the interface presented by an operation, and whkh 
helps to separate the externally visible behavior of an operation from the internal processes that 
produce that behavior. 

We assume that an operation terminates whenever it raises an exception. Thus an 
operation may terminate m any one of a number of conditions, one of which is normal and the 
rest of which are exceptional. In general, the results of the operation in each condition will be 
different, arid mtist be specified for all possible termination conditions in a complete description 
of the operation. 

The alternative to our point of view is to allow an exception to cause some events, and 
then to continue performing the original operation at the point where it left off. This 
alternative is not attractive because the separation between the specifications of an operation 
and the details of its implementation breaks down. Given a specification of an operation that 
describes the results of the operation for the normal termination condrtton and giv« the* 
conditions under which each exception occurs, and given a specification of an exception 
handler for each exception raised by the operation, we still do not have enough information to 
predict the behavior of the operation in the context of the specified exception handlers. It is 
necessary to analyze the implementation of the operation with respect to the specifications of the 
exception handlers in order to determine the effects of the operation. Since different 
invocations of the operation can occur in the contexts of different exception handlers, we cannot 
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treat an operation as a closed module if we adopt the resumption model ofexceptton handling. 
Exceptions are discussed further in Chapter 2. 

5. Own Dnta. 

We assume that the operations of a data abstraction are functional. This means that 
an operation must not have any internal state, so that the results of an operation depend only 
on the information contained in the data objects passed to the operation as arguments (which 
may include references to other objects). Data objects may themselves have states, so that we are 
not excluding the possibility that an operation may return different results if it is invoked with 
the same arguments at two different times. This restriction is meant to prohibit type managers 
(ie; SIMULA classes, CLU clusters, ALPHARD ^ fwrns. etc.) from keeping mutable own data, 
which introduces a component of the state associated with the type as a whole, rather than with 
the individual data objects. This issue is discussed further in Section 3.2. 
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Appendix II - Basio Type Definitions 

The definitions of the natural numbers and the integers are imported; dteectly from 
the underlying standard mathematics. The definition of the natural number abstraction is 
shown in Figure 21 As in the definition of sot in Chapter 4, the standard notations for 
natural numbers and integers are used in the definitions of the operations to refer to the 
standard operations of the underlying mathematical domains, while the same notations are 
introduced as abbreviations for the operations of the exception algebra, for use in the 
definitions of other modules. The only nonstandard feature of this definition of the natural 

Figure 24. Natural Numbers 
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numbers is the infinite parameterized family of constants. These operations are introduced $p 
that we can use the familiar decimal notation for natural numbers in our specification language, 
rather than having to build up each number from zero using the successor function, which 
quickly gets cumbersome 

The definition of the integers is shown m Figure 25. Integers also have an infinite 
supply of constant operations. Note the con version operations integer ind nn, which serve to 
convert integers to natural numbers and vice versa. The quotient and remainder operations 
have exception conditions in the cases where the standard mathematical definitions are 
undefined. The qumem operation rounds tftowfl irrespective of the sign of its arguments, in 
agreement with the usual mathematical definition, and in contrast to the way division works in 
most programming languages (eg, FORTRAN). 

The astute reader will have noticed that we have omitted the definitions of the 
operations >, *, <, and >, even though we have used them freely m the specification language. 
The astute reader will also be able to supply the standard o^nWirfimi'ifor these operations, and 
is advised to do so. 

These types are intended for use in the specification language. The corresponding 
types for a programming language should pro©aoty be designed differently, to include 
limitations on the sizes of the numbers, exception conditions fdr cases in which those size 
limitations are exceeded, and additional operations for converting strings of decimal digits into 
numbers, and for printing out numbers. 



Figure 25. Integers 
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I xl-*l 




a as argl ♦ arg 2 






difference: 


i x r-»i 




as arg 1 ♦ arg 2 






times: 


I x I — » I 




••argl* arg 2 






quotient 


I x I — > I 


♦ (zerojdivide : > 








remainder: 


Ixl-*1 


♦ <zero_d4vide : } 








abs: 


I-M 




as I arg 1 1 






nn: 


|-*n«t* 


<wrong_j|p* : > 


•■ -ty ;-^r ; • 






less: 


1x1—* boolean 


as arg 1 < arg 2 






equal 


1 xj -^booteaa 


,-#s,argri;» arg 2 




representation 


integers Z 






;■,.'■. ' .;.•■;.< •;•■ ■' '"■■ ■""'•""• 




restrictions 


none 




; ,i . . -; 


■.-:■;■. ■■■-" . 




Identity 


inttequal 










operations 


constanttnX) ■ 


< n 









integer(n) » n in Z 

minus(x) = -x 

difference(x, y) - x - y 

times(x, y) - x * y 

quotientfx, y) - if y - then derojdivide : > 

else q : 3r[ x - q * y ♦ r & < r < abs(y) ] 
remainder(x. y) =■ if y - then CwrojEliifide : ) 

elser:3qfx-q*y*r*:0<r< abs(y) ] 
abs(x) - |f x < then -x efe* x 
nn(x) * if x < then <wrong_sign : > else x hi N 
less(x, y>- x < y 
equaKx, y) = x - y 



end int 
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Appendix III - Proofs 

An exception -algebra differs ftom a heterogeneous a^cbrfaf defined in{|] by having 
a disjoint union structure for the ranges of the operations, where the disjoint union is indexed 
by termination conditions, and where the components of the disjoint, union are cartesian 
products of the phyla. In a heterogeneous algebra, the range of each operation ha* to be some 
phylum of the algebra. The definitions of basic algebraic concepts such as u&algebras, 
congruence relations, quotient structures, and homomorphisms have to be adapted slightly to fit 
into our framework The required extensions are concerned mostly with termination conditions. 
For example, a congruence relation is m equivatenct relation that preserves all of the 
operations of an exception algebra, so that if corresponding ^argument* of an operation are 
related by the congruence, then the termination conditions, qf the Vm invocations must be 
identical, and corresponding return values must be related by the components of the congruence 
relation for the appropriate phyla. As in tllan wjuivalence relation on an exception algebra It 
defined to be an indexed set of equivalence relations, one tor each phylum. 

Theorem 2: Every equivalence class of static models with respect to the behavioral equiva fence 
relation contains a reduced model. 



Proof: Let E be an equivalence class of models with respect to behavioral equivalence, 

and choose Af < £:This wiWAIwWysteptiisible?' " 

since equivalence classes are nonempty by definition. 

Let Af ' be the subalgebra of M containing wily the reachable objects of the principal type. 

and with the same subordinate types as M. 

M' is closed with respect to the operations of Af , since it contains all reachable data objects. 

M' is behaviorally equivalent to M 

since the value of any closed computation C in Af is the same as the value of C in M. 

Let Af" = M'l=, where = is the external equivalence relation defined in Chapter 3. 
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TiLn l^^^^Jl " ** COmiSteW Wlth a " * th * «P«*» ■* construction. 
Then Af is reduced and behavior a My equivalent to Af 

Every element of the principal type of Af is reachable, 

because any such element is equal to M fbr **ummI« prtnOpaty^of Af>, 

*nd every such * ft reachable, by the construction of Af 

bT^^^^S^ rf *■■•- «— *^*~ r „ Mentical. 
Hence M " is reduced. 

.^l^!f aV ! 0ra, I y . eqU ' VS,1ent t0 "' bMMne * ,$ a h""°"»rpMc image of Af\ 

under the natural homomorphism h defined by Jft* Wtf *c^fj«4Ar) « * otherwise 

wfcere rf is the^riheipa? type of At'. otherwise. 

Since behavioral equivalence is transitive, 
Af" is ©erwmorally equivalent to AT. 
and the theorem is established. 
End of Proof : - 

Theorem 3: Ff two reduced models are behavioral equiyalwt. than ll^-r^tomorpWc. 

Proof: Let Affand Af2 be reduced and behaviorally equivalent 
Define the isomorphism /as follows. 

For every cto s«f tomputatton C, ler/fvaMC, Af I) 1 vahie(C. Af 2) 
By Lemma I below, whenever valued, u\) , valued' Afl) 
then v.lw<C.Af 2) - valued'. Af2>; W -* f 

so that/ is single valued, and hence a function 

a^in^Tr^ ^*^^™g>"g Wf ^ Af2 in the above definition. 

and it is also single valued, by the same argument 

So/is I: I. ■■-■■-■ - r - ' "'- - : -- ■--■'■-■"■■' ' ....-.•-, 

The operations of the algebra are preserved by construction, 
so the isomorphism is established. 
Emf»f;Pr»of »>'• 

Lemma I: Let ATI and Af2 be behaviorally equivalent exception algebra models, let C and C be 
closed compuM«ons. and let valuefC. Af I) . valued Tkm ■>***& M 2) is «xtem.Hy 
equivalent to vahiKC, Af 2). : f 
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Proof. let Af I and Af2 be behaviorally equivalent exception algebras, 

let C and C be closed computations, ? 

Jetvalue(C, Afl) = valuefC, Afl), 

and let CO be an open computation. 

Then value(C0, valuefC". Af ), M ) - nUieiC'tCOtMk 

for any exception algebra Af , « ' 

where C"||CO is the concatenation of the computations q" and COTjf. tength(CO)], 

and where the step indices of all of the argument specifications in CO 

have been increased by length(C"H 

then value(C0, valued, Af2), Af 2) = u r 

value(Ci|C0,^2) - by the definition of *«katen*tion, 
value(C||C0. Ml) - since Afl and Af2 are behaviorally equivalent 
valuefCO. valued, AfJ),Afl> = 4>y rtwn!f«ft#iWotf6tyortdfenation 
value(C0, valuefC, Af I), Afl) = by assumption. 
valuefC'IICO. Afl) = by the definition of concatenation, 
value(C'||C0, Af2) - since Ml and M2 are behaviorallfequivalent 
value(C0, valued, Af 2), Af 2) by the definition of concatenation 
So value(C, Af2) is externally equivalent to value(C', Af2). ** !i:rt "' 
End of Proof 



Theorem 4: If Af is behaviorally equivalent to Af* and ^Af is reduced, then, there i* a 
homomorphism from a subalgebra of Af ' onto Af . 

Proof: Let Af "he the subalgebra of Af" containing only the reachable 

objects of the principal type of Af', 

and with the same subordinate types as Af \ 

The quotient of Af " with respect to the external equivalence relation is reduced 

and behaviorally equivalent to Af by Theorem 2. ' ,, 

and by transitivity of behavioral equivalence, it is also behaviorally equivalents Af 

Then by Theorem 3, the quotient is isomorphic to Af. • 

The composition of the natural homomwphismJroiM*" to*M quotient and 

the isomorphism guaranteed by Theorem 3 is a homomorphism from Af" to Af 
so the theorem is established. 

End of Proof 



Theorem 5: Every chain of algebras with respect to E has a feast uppet hound 
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Proof: Let A f : i < N be a chain of algebras with respect to E. 

Then A -= U A,, where A is defined as follows. 

i'(M 

Va < A. typenames [ A. phyb a - U A i .pbyU a \ 

V0 c /f. earnest,!, operation^.. U ^. operations^ J, 

-4. x « U ,*..*, 
ic N ' 

where x can be any one of the following components: 

typenames, opnames, tcrames. argkngth, argtype, tc, rlength, rtype, or pt. 

By Lemma 2 the operations and tyr« cle4«tp«ion OffKttons are Well defined 

iff Eyf for all/ < N. 

since*. £. U s-lorany}(H. ^ 

So >4 is an upper bound for the chain A t . .,,. 

If ^ E B for all i c N then A c B, 

since j. £ 5 for all i ( N implies U j,cj. 

MM* 
So A is the least upper bound for ihe chain x A t . f vi , 

Em* of Proof ' ' "' r '"'" ' '"-'■'.■'"•' 



Lemma 2: If /. : f e N is a chain of functions with respect to C, then/- U /, is a well 
defined function. 



Proof. We have to show' that/- U f t is single varied. 

Proof by contradiction. 

Suppose/ is not single valued. 

Then for some x, <x, aHs/antM*; #^< / where a * fc . 

Since/- U /,. 

i c N ' 

pick n, m such that <x. a) < / n and <x, *> c / w . 
Since/;- is a chain./,, £/ max(n m) an d/ w j;/^^ ^ 
So <x. «> c /^^ n) and <x, fr> c / ( ^ where «i« ^ 
But/; is a single valurd function for all* c II, contradiction. 

So/mmt be single valued. 
End of Proof 
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Note that we arc ti rating a function /as the set of a#f«if*<Xv/(j# such that x c domain</) 
Theorem 6: The tuple transformation is continuous with respect to G. 

Proof: Let A^ be a chain with respect to £. 

Let U denote the least upper bound with respect to Ei = 

(U ^)xJ 2 x...xS„= U ( A, x So x ... ->e«w * !■•■ : 

/ c N c i ( H *■ n 

from the definition of union and cross product. 

The definition of each operation is a functional F from the phyla to operations on the phyla, 

with the property that the value of an operation on any input depends only on the input values, 

and not on the phylum as a whole. 

(The finite quantification in the" definition of equal can be expanded , 

into an equivalent finite conjunction.) 

So F{U Sfa) = F(SjKx) for any S such that * c S ' 

F(SMx) is undefined if -x f 5, ^ 

So F (U 5,-Xx) = U F(S-Kx). 

The definitions of the signature fitiktmttttmhMveHHttptiftlhff 1 ' ,jih ; v J ' 
So the tup+et»^mforr»atione«alj^r»$i*cwtJfluo^ w«h resp^fOC. 

End of Proof >,>,-<-. ^--i ■_ 

Theorem 7: Let Afl and M2 be complete exception^^ff fttoWs^wfth fl^Saiiie signature and 
the same interpretations fc* the suhofdinafr*|yr^,a^ from Afl to 

Af2, such that h is the identity mapping on aH c^ the subordinate types. Then Afl and Af2 are 
behavioralJy equivalent. 

Proof: For every finite closed computation C, we have to show that: 

A. C is feasible in M\ if and only if C is feasible in Af2. 

B. value(C, M\) = value(C, Aflj) whenever C is feasible in Af I and produces a boolean value 

//nrfiV,- <: -- i, ■-' "■ * .": :■••■-■:' 

Let H(C) = ( feasible, Afl) = few»ble(C,*f2nfr 
( length(C) > I fc fcasibfefcJfOM* Atvatae&s; Mi))?* vahw<t, Aft K s 
Assuming that H(C) holds for all C such that tength(C') < tength<C), 
show that H{C) holds. 

Casel: length(C) = ; 
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H(C) is trivially trite, since the antecedent of the implication is false. 

A. holds since the empty computation h feasible in any model 

B. holds since there are no computattoroof lengfh pro duc ing a bodtam value. 

Case 2: length(C) > 

Let tength(C) « n and let C - C[l .. nil 
Then W(C) since length^*) - n-l < ten#h<C). 

A To show feasible, Aft) if and only if feasible^. M2) 

Case 21: C is not feasible in Ml. 

Then by the induction hypothesis H(C), C is not feasible in-A#2. 
Since C* is a prefix of C, C is not feasible m MTor M2. 
So A. holds for case 2.1. 

Case 2.2: C is feasible in M I. 

Then by the induction hypc*besisC is feastt)leio^M2 

Therefore the teroWnation <oaiditi«ns of the afgumorts natch the tenements 

for every step of C in both models. 

C is feasible in Mi if and only if the termination conditions of the arguments of CM 

match the requirement* of step Cfal 

where tength(C f ) > 1 and where C y is a proper prefix of C. 

By the JnxfwfliBW HypoTttelKvfllMe^ ^fi*vaWe{e^M2V 

Then tc<A<value(C f . Afl» - tc^value^. M2». 

since hctm^morphiims preserve termination conditions. 

Therefore the arguments will match the requirements for the interpretation of 

C in M2 whenever they will match for the interpretation of C to M2. 

So A. is established for case 2.2. 

B. Assume C is feasible in Ml and tehgth(C) > I. 
Show Mvaluefc., Ml)) = vahie(C, M2) : 

Each argument x t of the last operation of C is the result of some prefix C t of C. 

where I < length(C t ) < len^th(C). 

By the induction hypothesis. MvaMC^ Ml) m vakte(C K M2). 

Since A is a homomorphism, * preserves the operations of Ml and M2. 

So Mvahie(C. Ml)) - vahietCi M2). 

So H(C) for all computations C. 

If the principal type of Ml is boolean then Ml - M2, 
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since there is a unique standard model for the boolean domain, 

and otherwise boolean is a subordinate type. 

In either case, * 000 j ean is the identity mapping. 

So if a computation results in a boolean value, 

it must result in the same boolean value in Ml and in M2. 

So M 1 and M 2 are behavioraNy equivalent 

Then H(C) holds for all finite computations C. 
End of Proof 



Theorem 8: Let Ml be a state machine model and let #2 be an exception algebra model with 
the same signature and the same interpretations rot the subordinate types. Let c be a 
correspondence function from Ml to M2, such that t returns its second argument for all 
subordinate types. Then Ml and M2«are behaviorally equivalent 

Proof. For every finite closed computation C, we have to show that: 

A. C is feasible in Ml if and only if £ is feasible in M2. 

B. value(C, Ml) = value(C. M2) whenever C is feasible in Ml and produces a boolean value. 

Let state(C, M) denote the final state produced by 

the interpretation of the closed computation C in the state machine model M. 

Let H(C) = ( feasible, Ml) = feasible^. M2))k 

( length(C) > I & feasible, Ml) ) => c(state(C. Ml), valued, Ml)) - value<C. M2> 

Assuming that H(C) holds for all C such that lengthfC*) < kngth(C), 

show that H(C) holds. 

Case I: lengthfC) « 

H(C) is trivially true, since the antecedent of the implication is false. 

A. holds since the empty computation is feasible in any model 

B. holds since there are no computations of length producing a boolean value. 

Case 2: length(C) > 

Let length(C) - n and let C « C[\ .. n-l]. 
Then H(C) since length(C") = n-l < length(C). 
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A To show feasible^, Af I) if and only if feasible^. Af2) 

Case 2.1: C is not feasible in Afl. , r 

Then by the induction hypotbtsli /y(C), C* is not feasibkr in M2. 
Since C is a prefix of C.C is not feasible M»WlprAf2i 
So A. holds for case 2.1. 

Case 2.2: C is feasible in Af I. 

Then by the induction hypothesis C is feasible in Af 2 

Therefore the termination <ondtfi«u of the Mgumem*4Wtch the requirement* » 

for every step of C in both modeb. 

C is feasible in i Af| if and only, if the tefnii^twn eoi¥Mtiow of the arguments of C[n} 

match the requirements of step Cfnl 

Each argument x, is the value of C/. j .r 

where length(C,) > I and where C i is a prefix of C. 

By the induction hypetrtesii <^te# /( A^, vrt*^C,, Af i) ■* ViWefC^***). 

Then tcMstatefC,. All), vakiefC,, Ml)) - tcCvaMC,, Af2)X 

since correspondence functions preserve termination conditions. 

Therefore the argumenB wW match th» r eo ^f f eme f ks for ^ l> '" 

the interpretation of C in Af 2 

whenever they will match for the 'mterp^itiwr of C In Afl 

So A. is established for case 2.2. 

B. Assume C is feasible in Af I and length^) > I. 
Show c(state(C. Afl), vahie(C. All)) - valued Af2>: 

Each argument x ( of the last operation of C is the result of some prefix Cj of C, 

where I < lengtMCf) < length(C). "" ' 

By the induclfen ffpth^si$, cfWte^ Af I), jakui(% A«) * vatae^ JW 2i , 

Since C^ is a prefix of C, c^statelEC,, Af I), xj) - c(Uatt(C, Afl), x t ), " \ * 

by the monotonkity property of correspondence functions. 

Since e is a correspondence function, c preserves the operations of Afl and Af 2. 

So f(state(C, Af I), value<C, Af I)) - vakie(C, Af2). 

So H{C) for all computations C, ,-,» „ : ..' 

By the hypothesis, of tfe (heorem, c U the identity mapemg on thebooksn donnin. 

So if a computation results in a boolean value, 

it must result in the same boolean vahie in Afl and hi Af 2 

So Afl and Af are behavioralh/ equivalent. 

Then H(C) holds for all finite computations C. 
End of Proof 
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AppeacUx IV - Bynt<tx 

The syntax of an abstract model specification is given below in an extended form of 
bnf. |XJ means that X is option*!, j^rge parentheses ( ) are symboh of the meta language 
used for grouping terms. Small parentheses and square brackets "CV T. T. and T are terminal 
symbols denoting the respective characters themsetve$ v X* mean»,X can b« repeated zero or 
more times. X* is the same as X X* (X may occur one or more times). 



<specification>::= <module> | <type definition > 
<module>:.« module <type definition^ end module 

<type definitions- type <typenarr«> [^ararrrtter llst>H<abbreviation>3 
[<requires>] s ' ■■"*>■ 

<signature> 

<rep spec> ! "'* 

<ops> 

[(auxiliary signawre>} 
[<deftnitions>] 
end <type name> 

<para meter list>;.-» [ (parameter name> {, (parameter name> f ] 
(abbreviation^:- as abbreviation body> 

<requires>n« requires <parameter type> ( , <parameter typo )* 

(parameter type>;:« <para meter rtame> : <type name> [ suck tfcat <^)redicate> ] 

<signatufe>::- with (function fcype»* 

<auxiliary signature>:.= internal <function type>* 

(function type>::» <function name> : [ <domain spec> ] — * [ <domain spec> ] (condition spec>* 

<domain spec>::- <type name> ( x <type name> )* 

<condition spec>::= ♦ < (exception name> : [ (domain spec> ] > 



-no- 

<rep spec>::- <domain equation>.[<ratrk3ion>|[<efttifaferKe>] 

<domain equation>::- <domain name* - <domain expression* 

<domain expressions:- <domain name> \ { <domain name** } 

I tuple* [ dabefcd expression tist> ] ] 

|onoe#r*lahirtedexpmtk>rH t u>)] 

I sett <doroain expre$sion> } 

I se<|oeneei<Qomim expression* j 

<labeled expression Itstx- <lat>eled expression* ( , <hbeied expression f 

<tabekd expre sslon>:- <Ubel> : <tlomatn cxpmsk>ri> 

<r«triction>:- restrictions none | restriction <Jdentifter> such that predicate* 

<equivalenc«>::- identity <operat»on name> 



<ops>::» operations <operatton definition** 

<definitions>::- definition <operation definition** ^ > 

<operation definition*:- <operatton name> <argument JBst> ^« «gej^f^^p, Jai9ci|»> £ t ^|pc3ils>>: ^| : 

argument list>::- [■< <ldentifi*r> ) ] ( <idemifier** ) " 

<operation body>::- <idenUf«r> | «pei^ w r«nK> <ej^teuion Usi> , 

I <klentifter> : <predfcate> 

I if <boolean expression* 
then <operation body> 
else <operation body* 
<expression list>::- () | ( <operation body> ( , <operatioh,boa>> }* ) 
<kxats>::« where ( <variabie> xoperation body* )* 



The grammar shown "above specifies enty the context free pert of tire language. 
There are a number of additional constraints that must be met for a weH formed specification. 
For example, the number of argument expressions to an operation in an operation body must 
be the same as the number of type names in the domain specif***** «f the Operation in the 
signature- 
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